Today I hacked together a little code to try out an idea I had. It's not much at this point, just two types (one inherited from the other), but with some work I think it would become an easy way to create and use miniwindows, as well as derive your own custom types of miniwindows. This is what I have so far:

This code defines two types, one a generic Window and the other a derived CharacterGrid. The CharacterGrid itself is adapted directly from a table I use in my MapWindow plugin. It's quite easy to use, as it hides the complex details away. The grid table itself is table of lines, which are tables of cells, which store 'char' and 'style' (color) information.

The implementations of the two widget types do leave something to be desired at the moment, but the interface that you use to manipulate the grid is simple.

Running this code produces a stamp-like 5x5 grid of blue X's. (I admit I was slightly surprised by this; I expected red. But I digress) Any thoughts and/or contributions would be appreciated, because while I'd love to see a set of MUSHclient window widgets, it's not something I'd care to undertake on my own.

It's an endian thing. If you look up red in the colour picker, you see:

MXP: #FF0000
JScript: 0x0000FF

The HTML/MXP system puts the red byte first, where you expect it (red/green/blue). But the actual computer word, which has has the least significant byte "on the left" so to speak, shows it as the low-order byte.

It's an endian thing. If you look up red in the colour picker, you see:

MXP: #FF0000
JScript: 0x0000FF

The HTML/MXP system puts the red byte first, where you expect it (red/green/blue). But the actual computer word, which has has the least significant byte "on the left" so to speak, shows it as the low-order byte.

(post=7918)

Yes, I recall encountering that once before. It just surprised me, is all. (I'm used to HTML/CSS and the #RRGGBB style)

@WillFa: It would be great to integrate those components into a Widget framework and make them reusable among other widgets. Would you mind if I tried adapting your code to the barebones demonstration I posted above (and perhaps took a few of your ideas)?

@Blainer: Yes. I went through that with a C++ class I called cConsole, when later I realized I could emulate nearly all of its output functionality with two custom stream manipulators (one for position, the other for color) which only took maybe ten lines of actual code...

local Caption = ""
for k,v in ipairs(TriggerStyleRuns) do
if not LookupColors[v.textcolour] then
-- Code to append to LookupColors if not found
end
Caption = string.format("%s@%s%s", Caption, LookupColors[v.textcolour], v.text)
end
MW:AddBar(Caption)

In your MapFinish trigger:

MW:Update()

The module really does more than just gauges, though it's original intention was to move the InfoBar function calls into a miniwindow

Here is a demo plugin that lets you play TicTacToe in a miniwindow. My implementation of the game itself is undoubtedly rather bad (note the CheckWin/CheckRow functions), but the purpose of the plugin is just to showcase the CharacterGrid widget.

The grid appears by default in the center of the screen. Hovering over any available space will display the current player's color/piece. It highlights each player's last move, and highlights a winning line in blue (and also locks the grid).

I've just committed a version that implements a very small subset of WillFa's InfoBox functionality. It's barely even begun, in my opinion, but some of the other functionality in InfoBox (like the gauges being collected together under a common frame) are likely going to be implemented as separate widgets altogether.

Not to be conceited, but I particularly like my implementation of the gauge effects. I think it makes it rather easy to define new (and potentially complex) gauge effects, and it simplifies the actual drawing code. I left off implementing fixed gradients because it was somewhat difficult for me to transpose the variables/logic used in InfoBox to my model, but I did create a substitute 'meter' effect, which simply places a line at the point of value.

EDIT: Latest source can always be found at my GitHub respository; see [1].

I think that this is really quite nifty -- I look forward to playing around with it more when I get the chance. Having a solid framework for common widgets will make developing "sub-interfaces" much more efficient.

Dang, I was working on something like this, thinking that an object oriented interface would be easier, but coding it in the first place is hard, and there's lots of stuff I don't really know. I was thinking it could make it so I could setup labels and buttons really easy, you know standard controls, maybe a listbox, stuff like that, but the problem is changing what's displayed, if you don't have a background drawn underneath, or you want to move the control somewhere, you need to clear the entire window and redraw everything, so you have to record everything to draw, and what order to draw it. Frankly, making a module for everything would probably be like 1000 times harder than any code you'd actually need to make with it(at least what I've done so far), and still might not do everything you'd want it to. I suppose a basic one wouldn't be two hard, where you simply put all the miniwindow functions in a general class, I already started something like that although I found it hard to continue working on it. It also has the problem of eating up memory making objects for everything. I find myself wondering whether it's worth it to make. Then again I do get bored easily when I have to figure out the mechanics of everything myself.

Edit: Hmm, to be honest it's the drawing order I was having a hard time figuring out, I suppose the rest of it you could have a table of controls on the form, with a field for the type of control, any miscellaneous data, etc. Hmm, I suppose... if it's an array, then the order of the array could be the z-order, but then I'd need another table to lookup controls by name... It all gives me a headache which is why I haven't gotten very far.

Edit: Not to mention you need to have it check whether the control or whatever still exists or not. God, I need to stop thinking about it before my head explodes.

Since I've already mostly set up the object/class system and organization, feel free to create your own widgets from what I have so far. If they're general-purpose enough (like a listbox), I'd be glad to add them to the framework. Check out CharacterGrid and Gauge for examples of how to derive a widget.

I've wrapped most/all of the Window*() functions into the Window base type, acting as a layer between the widget code and MUSHclient. I aimed for simplicity and intuitiveness where I could; for example, I split the WindowCircleOp() and WindowImageOp() functions into multiple methods, each corresponding to a separate value of the 'action' parameter.

After a long while deliberating my options, I felt that wrapping the Window*() functionality this way would be the easiest way to implement window "frames" similar to those surrounding windows in Windows. For simplicity, I wanted (0,0) to correspond to the upper-left edge of the "inside" of the frame, rather than the upper-left of the frame itself. This is a similar setup to the Win32 behavior anyways, though it will still be entirely possible to draw on the borders by supplying negative coordinates.

The only part I'm not really happy with is WindowRectOp; I'm not really sure how to break that down. WindowCircleOp allows for the drawing of rectangles, covering RectOp's actions 1 and 2, and I separately created an InvertRectangle() method to cover action 3. The rest I'm not sure about.

While there certainly aren't many widgets available yet, the Window layer alone might be fun to play with. I'd appreciate it if anyone else could test it out and let me know what their feelings are.