08 Dec, 2009, Twisol wrote in the 1st comment:
Votes: 0
First off, thanks to Davion for creating this forum. :biggrin:


For the past couple weeks I've been working on a widget framework based on MUSHclient's minwindow functionality, with the goal of making it easier to add miniwindows to your plugins. I've already created two relatively simple widgets, a CharacterGrid and a Gauge, with more on the way. I've also created a demo TicTacToe plugin to showcase the CharacterGrid's functionality.

You can find the framework here. Click the Download link to the right of the project title, and unzip into (MUSHclient root)\lua. Rename the resulting folder to 'MWidget'. To use the framework, simply require() the widget(s) you want to use. For example:

local CharacterGrid = require('MWidget.CharacterGrid')


A single global table is created as well, called MWidget, which contains all of the currently-imported widget definitions, and is required for widget hotspots to work at all. Basically, don't mess with the MWidget table and you'll be fine.

I'd appreciate any feedback (or assistance!) with the framework!

[link=file]2728[/link]
11 Dec, 2009, David Haley wrote in the 2nd comment:
Votes: 0
Such frameworks are very cool, as they make it much easier to create customized interfaces using MUSHclient itself as a framework. Writing a client is a lot of work: you need to handle an awful lot of stuff. Having a client already built for you is very convenient when you can layer your own graphical interface on top of that client. Work like Twisol's will make it easier to do that layering, because you will be able to skip implementing basic functionality for common GUI elements. I for one will be following this closely, and perhaps contributing to it at an unknown future point when I start working on client development. :smile:
13 Dec, 2009, David Haley wrote in the 3rd comment:
Votes: 0
Twisol, I think it might be nifty if you took a look at the various discussions on ZMP and see if you could easily support the widgets in there. Then a ZMP plugin for MC would allow easy testing of ZMP in MC, and since MC already supports very nifty miniwindows we can play with graphics etc.

One widget that I would find particularly useful but also probably a little annoying is a scrollable window. In an ideal world, the scrollbar should be agnostic as to the contents of the window (chargrid, text only, graphics, …).
13 Dec, 2009, Twisol wrote in the 4th comment:
Votes: 0
ZMP's specification sounds nearly exactly like ATCP, so I feel right at home with it now :cool:. I think that the zmp.subwindow commands would best be supported directly by a separate plugin which manages the ZMP windows, rather than directly by the ZMP plugin. Just like how my ATCP plugin operates, I don't think a ZMP plugin should do anything non-essential to the workings of the protocol, and it should offload operations to other plugins that listen for its ZMP events.

The scrollable window sounds quite plausible, considering the save-components-as-images approach I'm trying to implement. Ideally, you could draw the image or the text buffer with arbitrary size, then use WindowDrawImage() to draw a specific portion of the component to the visible region. A scrollbar would ideally just modify the parameters of the visible region.
13 Dec, 2009, Twisol wrote in the 5th comment:
Votes: 0
I should note that I'm not a fan of letting the server directly control your miniwindows. I believe it would be better to simply make the extra data or resources available through some interface - ZMP is a likely candidate - and create plugins for the windows you want to supply. Users can easily pick whichever views they want, and of course create their own. It just doesn't seem like managing graphical views is something a MUD server should be doing directly.

I suppose one big benefit of letting the server control the windows is that it doesn't need to know a client's specific window interface, but I'm don't particularly like the approach…
13 Dec, 2009, Scandum wrote in the 6th comment:
Votes: 0
Might want to have a look at MSDP as a data protocol. Its main strength is ease of implementation.
13 Dec, 2009, David Haley wrote in the 7th comment:
Votes: 0
Twisol said:
ZMP's specification sounds nearly exactly like ATCP, so I feel right at home with it now :cool:. I think that the zmp.subwindow commands would best be supported directly by a separate plugin which manages the ZMP windows, rather than directly by the ZMP plugin. Just like how my ATCP plugin operates, I don't think a ZMP plugin should do anything non-essential to the workings of the protocol, and it should offload operations to other plugins that listen for its ZMP events.

Agreed – the ZMP plugin itself would be only responsible for parsing the commands and generating the events/making callbacks/whatever. Other modules would deal with implementing the ZMP commands.

My hope is that your framework could render near-trivial the implementation of the ZMP subwindow command handler. So the real work would be your framework, the ZMP parser, and then the layer in between would be quite easy.

Twisol said:
The scrollable window sounds quite plausible, considering the save-components-as-images approach I'm trying to implement. Ideally, you could draw the image or the text buffer with arbitrary size, then use WindowDrawImage() to draw a specific portion of the component to the visible region. A scrollbar would ideally just modify the parameters of the visible region.

This sounds like a pretty reasonable implementation. It might get complicated for long scroll-back windows. But if the window has a lot of scroll-back, it's probably text, in which case you could implement things differently.

The scrollbar only really needs to care about logical window size being scrolled. The underlying window, if it is text, could compute and return that without rendering the entire image. A more complex window using graphics etc. would render the image as you describe and then render a "window" onto the window. (Erk, vocabulary overload.)

Twisol said:
I should note that I'm not a fan of letting the server directly control your miniwindows. I believe it would be better to simply make the extra data or resources available through some interface - ZMP is a likely candidate - and create plugins for the windows you want to supply. Users can easily pick whichever views they want, and of course create their own. It just doesn't seem like managing graphical views is something a MUD server should be doing directly.

I suppose one big benefit of letting the server control the windows is that it doesn't need to know a client's specific window interface, but I'm don't particularly like the approach…

It depends on what you are doing with the miniwindows. There are reasons for a server to specify position to some extent, if the position of miniwindows is somehow relevant to the cohesive experience desired. The idea here is not just to let users populate miniwindows with triggers etc., but to provide an entire experience along the lines of what Nick and Lasher did for Aardwolf – but pushing it even further. I have no objection of course to letting the client move around windows later.

It's not so different really from graphical game interfaces in which you have floating dialogs that you can move around, but whose contents are controlled by "the game" (whether or not that is the server or the game client is almost irrelevant as far as the player is concerned, if they have no other control).

Scandum said:
Might want to have a look at MSDP as a data protocol. Its main strength is ease of implementation.

MDSP is not sufficient for the desired purpose.
13 Dec, 2009, Twisol wrote in the 8th comment:
Votes: 0
David Haley said:
It depends on what you are doing with the miniwindows. There are reasons for a server to specify position to some extent, if the position of miniwindows is somehow relevant to the cohesive experience desired. The idea here is not just to let users populate miniwindows with triggers etc., but to provide an entire experience along the lines of what Nick and Lasher did for Aardwolf – but pushing it even further. I have no objection of course to letting the client move around windows later.

It's not so different really from graphical game interfaces in which you have floating dialogs that you can move around, but whose contents are controlled by "the game" (whether or not that is the server or the game client is almost irrelevant as far as the player is concerned, if they have no other control).

I'm taking some inspiration from World of Warcraft's addon system, in particular the way they offload the entire UI to their own pre-supplied pseudo-addons. You can modify or even fully replace their UI entirely from the client-side, which is great. Giving control of UI positioning to the server compromises this flexibility, especially because it would require extra infrastructure to allow the user to "turn off" the server-supplied views. I don't think it's particularly difficult to take the WoW route, barring the previously mentioned stipulation of having to know the target client's scripting interface.


Scandum said:
Might want to have a look at MSDP as a data protocol. Its main strength is ease of implementation.

It looks interesting, but quite similar to ATCP and ZMP. While ZMP might be more complex due to its packages, it also seems a lot more conducive to transport of complex data and operations. Plus, I already have an ATCP plugin (which was also rather easy to implement), so it should be an absolute cinch to modify it for ZMP.
13 Dec, 2009, David Haley wrote in the 9th comment:
Votes: 0
Twisol said:
I'm taking some inspiration from World of Warcraft's addon system, in particular the way they offload the entire UI to their own pre-supplied pseudo-addons. You can modify or even fully replace their UI entirely from the client-side, which is great. Giving control of UI positioning to the server compromises this flexibility, especially because it would require extra infrastructure to allow the user to "turn off" the server-supplied views. I don't think it's particularly difficult to take the WoW route, barring the previously mentioned stipulation of having to know the target client's scripting interface.

Oh, I see what you mean now. Well, this is the old problem of describing the data vs. describing how to describe it.

The advantage to implementing server-side control at first is that it very easily lets you prototype things as you're figuring out what you want to do with it. As developer(s) and tester(s), it's ok to live with the server setting out the rules of the game.

I agree that client-side control is preferable in the end of the day, if the server is providing semantic data rather than presentation data. The difficulty is that it's hard to predict at first what exactly that semantic data is, and it's likely to be rather different from game to game.

So I think that implementing support for ZMP subwindows is a good first start, but that a game that wanted to get serious about this sort of stuff would need to communicate the data semantics, and provide pseudo-addons as you say to render it on the client.
13 Dec, 2009, Runter wrote in the 10th comment:
Votes: 0
How complete is ZMP? I've wanted to look into it but because it seemed to be still be somewhat incomplete I've been waiting.

I also am looking into your framework. I'm currently considering building a custom client interface from MC.
13 Dec, 2009, Twisol wrote in the 11th comment:
Votes: 0
You might not want to do any in-depth development with the framework at the moment, it's moving through a fairly extensive overhaul to support widget composition. This is my first attempt at any kind of UI framework, so bear with me. :rolleyes:
13 Dec, 2009, Tyche wrote in the 12th comment:
Votes: 0
There's also MCP which is supported by 7 or so clients, mostly used by MOO/MUSH/MUCK servers.
13 Dec, 2009, Twisol wrote in the 13th comment:
Votes: 0
In the end, a choice of protocol won't have much (if any) effect on the design of the widget framework; any contact between the two would be mediated by one or more separate plugins.
14 Dec, 2009, Scandum wrote in the 14th comment:
Votes: 0
Twisol said:
It looks interesting, but quite similar to ATCP and ZMP. While ZMP might be more complex due to its packages, it also seems a lot more conducive to transport of complex data and operations. Plus, I already have an ATCP plugin (which was also rather easy to implement), so it should be an absolute cinch to modify it for ZMP.

ZMP is difficult to implement on Diku servers because it uses NUL bytes. Why not create an interface for both MSDP and ZMP?

Another advantage of MSDP is that 22 MUDs already implemented its sister protocol MSSP which is pretty much identical.
14 Dec, 2009, Twisol wrote in the 15th comment:
Votes: 0
Well, again, the framework itself is completely MUD-agnostic, and could be used completely offline (for example the TicTacToe plugin I've uploaded here). The actual protocol interfaces would be done in separate plugins that act as a layer between the server and the framework, which the framework doesn't need to have any knowledge of. To the framework, it's just another end-user.
14 Dec, 2009, David Haley wrote in the 16th comment:
Votes: 0
Scandum… MSDP is not sufficient for implementing the stuff we're talking about here. The problem is not just shuffling data from server to client, after all.

And ZMP is easy to implement. I don't know why these NUL bytes are supposed to make things so terrible. For somebody who has previously said that if people can't implement something, it's their own fault for being stupid, it's kind of weird that here you are saying how other protocols are so hard and yours is so easy. :wink:

Back on topic, yes, the MUSHclient framework that Twisol is working on is completely separate from ZMP, FooP, BarP and BlahP. I brought it up only as a chance to be able to easily prototype the ZMP windowing commands. The general ZMP framework is rather generic, so it would be a good starting point for implementing the kind of rich semantics communication that has been talked about.
14 Dec, 2009, Scandum wrote in the 17th comment:
Votes: 0
Twisol said:
Well, again, the framework itself is completely MUD-agnostic, and could be used completely offline (for example the TicTacToe plugin I've uploaded here). The actual protocol interfaces would be done in separate plugins that act as a layer between the server and the framework, which the framework doesn't need to have any knowledge of.

Saving yourself quite a headache there. :)

David Haley said:
Scandum… MSDP is not sufficient for implementing the stuff we're talking about here. The problem is not just shuffling data from server to client, after all.

If that's the case I suggest we discuss ftl while at it.
20 Dec, 2009, Twisol wrote in the 18th comment:
Votes: 0
I'd just like to mention briefly that a new version of the framework has been pushed to the repository. It includes major changes to the fundamental flow of the framework, but some of the major points of note are: Widget composition should be working properly, though it may not be immediately obvious how to take advantage of it in this revision; hotspot functionality is fully disabled due to fundamental changes relating to composition, but work is in progress to bring it back better than before; and only the Gauge widget has been updated, but it should be quite easy to use.

Some sample code to create a simple gauge and display it:
require("MWidget")
Gauge = MWidget.Load("Gauge")

g = Gauge.new(100, 50) – width, height
g:SetEffect(Gauge.effects.meter, 0x0000FF, 0xFF0000)

v = g:GetView() – Create a physical location to display the gauge in
v:Refresh() – Update the contents

g:Value(50) – set the gauge to 50%
v:Refresh()


Now that I think about it, I'll probably also split the repository into two git branches, a development branch and a stable branch. Yet another thing to do tomorrow…

Link for those interested: http://github.com/Twisol/MUSHclient-MWid...
20 Dec, 2009, kiasyn wrote in the 19th comment:
Votes: 0
So, I downloaded it, set it up and:

Error number: 0
Event: Run-time error
Description: [string "Script file"]:2: module 'MWidget' not found:
no field package.preload['MWidget']
no file '.\MWidget.lua'
no file 'D:\Programs\MUSHclient\lua\MWidget.lua'
no file 'D:\Programs\MUSHclient\lua\MWidget\init.lua'
no file 'D:\Programs\MUSHclient\MWidget.lua'
no file 'D:\Programs\MUSHclient\MWidget\init.lua'
stack traceback:
[C]: in function 'require'
[string "Script file"]:2: in main chunk
Called by: Immediate execution
20 Dec, 2009, Twisol wrote in the 20th comment:
Votes: 0
Quote
no file 'D:\Programs\MUSHclient\lua\MWidget\init.lua'

This tells me you probably didn't set it up right. You should have a MWidget folder in the lua directory containing the Libraries and Widgets subfolders, as well as init.lua.

Edit: Something like this.
(MUSHclient root)/
|
+- lua/
|
+- MWidget/
|
+- Libraries/
|
+- Widgets/
|
+- init.lua
0.0/23