Print

[BenJeremy]

UI Specifications White Paper

This is a very rough first pass, and far from complete. How about helping me out with suggestions and notes?

[geniusalz]

A few things about the multiline text control:
Will it behave pretty much like notepad?  I guess it will need horizontal and vertical scrollbars (unless text wrapping is implemented).
An easy way to navigate the text is required (shift+up/down/left/right).  When switching lines, the cursor should maintain it's horizontal position (you can probably figure out how to do this; I couldn't)
Copy paste can also come in handy, introducing the issue of selecting text (other shift button, possibly)

I'm saying this all because the multiline control can serve as the basis for a very useful text editor.

As for the tree control, I assume the internal workings will be similar to XML structures.  Could serve for an XML editor (of course it won't be needed anymore, but that's another story )

I guess listboxes can also work as menus within scripts (possible option to hide the scrollbar)

'Visible' is one of the more useful attributes of controls IMO, and should be accessible from scripts.

Other enhancements (like captions for checkboxes) can probably wait.

I don't really know how menus would work, but I'm assuming they will be similar to the system menu.  Nothing much to say about that.

I was thinking of a download manager too, that can do preview videos, savegames (haven't looked into too much detail for that), skins, etc

And the installer is useful as well (can check on startup for archives present in the installs folder, or have the user select 'install' from the actions menu)

I guess we need dialogs for selecting files/folders, as well as some predefined messageboxes (yes/no, ok/cancel, etc)

That's about it for now

*long post, but relatively non-rambling

[ub312g0d]

wow, this reminds me soo much of vb its insane, but for a good reason I suppose.  How about adding a picture box so that icons and the such can be used as well.  I assume that the radio buttons would be able to be put in a control array as well.

[BenJeremy]

QUOTE (geniusalz @ Feb 7 2004, 02:47 AM)

A few things about the multiline text control: Will it behave pretty much like notepad?  I guess it will need horizontal and vertical scrollbars (unless text wrapping is implemented). An easy way to navigate the text is required (shift+up/down/left/right).  When switching lines, the cursor should maintain it's horizontal position (you can probably figure out how to do this; I couldn't) Copy paste can also come in handy, introducing the issue of selecting text (other shift button, possibly) I'm saying this all because the multiline control can serve as the basis for a very useful text editor.

Well, some of the logic is in place for the multi-line control - the key part is the "carat" - the cursor seen in the Sinle line edit control (and what you see currently when using StringEdit in AS.

I get locational information of where the Carat is from the text drawing routines and can draw the carat as well (since the font drawing routines know exactly where to put it).

The big question is how much work it will be to add scroll bars, position the text, etc...

QUOTE

As for the tree control, I assume the internal workings will be similar to XML structures.  Could serve for an XML editor (of course it won't be needed anymore, but that's another story )

Yes... I might be able to create a derivitive control that looks at an XML node and provides click-access to the specific node or element.

QUOTE

I guess listboxes can also work as menus within scripts (possible option to hide the scrollbar)

Well, that's what the menu will be for. The main thing for pick lists will be things like a skin picker (I plan on supporting the ability to pick which skins will be displayed, and if more than one, you will be able to see them randomly appear on each startup (only the ones you chose, though).

QUOTE

'Visible' is one of the more useful attributes of controls IMO, and should be accessible from scripts.

Yes, there are, of course, generic attributes that I left off the document.

QUOTE

Other enhancements (like captions for checkboxes) can probably wait.

Hmmmm... actually, it's probably a good idea to include that now. It shouldn't be that hard to throw in there.

QUOTE

I don't really know how menus would work, but I'm assuming they will be similar to the system menu.  Nothing much to say about that.

You can see how the menus will be set up by looking in the internal.xml - I hope to switch over to that soon.

QUOTE

I was thinking of a download manager too, that can do preview videos, savegames (haven't looked into too much detail for that), skins, etc And the installer is useful as well (can check on startup for archives present in the installs folder, or have the user select 'install' from the actions menu)

Good ideas.

QUOTE

I guess we need dialogs for selecting files/folders, as well as some predefined messageboxes (yes/no, ok/cancel, etc) That's about it for now *long post, but relatively non-rambling

MsgeBox will have support for buttons and icons... there will also be some other 'common' dialogs like OpenFile, SelectPath, etc...

[BenJeremy]

QUOTE (ub312g0d @ Feb 7 2004, 03:01 AM)

wow, this reminds me soo much of vb its insane, but for a good reason I suppose.  How about adding a picture box so that icons and the such can be used as well.  I assume that the radio buttons would be able to be put in a control array as well.

Yes, I will have to include an Image control.

Also, you'll notice the GROUP attribute on radio buttons. This will be a unique identifier for each button.


Since the data will be maintained in an XML node, you'll be able to associate just about any data with an individual item, too... should be handy to avoid complicated switch statements when a radio button or listbox item is selected.

[BenJeremy]

I updated the document online again, to clarify a few things.

I will try to continue updating it. As I am working on these controls now, please add your concerns and ideas here "ASAP"  

[geniusalz]

Had a look at the menu.  All the ID's are confusing me to no end (are they repeatable in different submenus?)

Is it possible to refer to them (and get the selected values) through names?
e.g.
MenuGetValue variable !.Configure.Localization."Date Separator"

Or just specify non-numeric ID's?

[flattspott]

That sounds awesome. When it's all finished we can have our own programing language, "MXM Basic"  

[BenJeremy]

QUOTE (geniusalz @ Feb 7 2004, 02:58 PM)

Had a look at the menu.  All the ID's are confusing me to no end (are they repeatable in different submenus?) Is it possible to refer to them (and get the selected values) through names? e.g. MenuGetValue variable !.Configure.Localization."Date Separator" Or just specify non-numeric ID's?

Well, I haven't started using it yet, but I may change the "ID" (as M$ considers this a special attribute for XML) to something like MenuID and MenuItemID.

Actually, while menu IDs should be unique, individual item IDs don't have to be. The Item IDs correlate to menu IDs when the type is SUBMENU, as this is the ID it looks for to bring up the submenu.

I may still have unique menu item IDs for many items in the config menu, just because I can centralize the handler and then I can re-arrange the menus as I need to (much like Windows' command IDs)

Just now, I moved the msgbox logic into the new ActionScript UI logic. I'm now adding support for handler, which I would prefer be handled through ONE location in a given ActionScript. The interaction is unbelievably complex to make everything work smoothly, and I don't want to hose anything up. My first run with MsgBox hung the system   but after a bit of head scratching, I figured out what was messing things up.

I may document the internal goings-ons for those that care.... let's just say the key word is "synchronization" - UI objects live in the main app thread, but actionscripts get their own thread.

[BenJeremy]

I've updated the document linked above....

ActionScripts will have a single entry point for all UI objects "OnEvent <Label>" as anything else just gets very complicated.

Nothing is final on the document, either... so expect changes.

[geniusalz]

The xml's seem a little 'clunky'

CODE

SimpleText      Text goes here

Is the 'Config' node necessary?  (Otherwise, the contents could be moved into the Control node)

Again, are non-numeric ID's acceptable?

[BenJeremy]

QUOTE (geniusalz @ Feb 7 2004, 07:17 PM)

The xml's seem a little 'clunky' CODE                  SimpleText      Text goes here       Is the 'Config' node necessary?  (Otherwise, the contents could be moved into the Control node) Again, are non-numeric ID's acceptable?

Yes, they do seem clunky, don't they. Feel free to take a stab at a decent dialog definiton and how it should look; I'll examine it and see if it fits what's goingto happen with ActionScripts and in use with internal MXM code.

As for non-numeric IDs, well, hmmmm... let me think about that. It's not a simple matter, and not efficient (though that may not be that much of an issue with UI objects)

[geniusalz]

Specifically, I was thinking of removing the Config node altogether (and moving the contents out).

CODE

Text goes here

Alternatively, the type could go as the node name (might require some work to implement, though)

CODE

Text goes here

Edit: On another note, isn't ENDCASE redundant?  It could use the already-present CASE/ENDSWITCH commands to 'end case'.

[BenJeremy]

Yes, ENDCASE is redundant at the end of a SWITCH block, but OK, ActionScript-wise

I'd prefer to at least keep the CONTROL node, because it's easier to parse them in proper order that way.

[geniusalz]

It's even redundant (sort of, not from a technical perspective, but logically) in the other case 'blocks'.

Switch 5
CASE 1
blah
ENDCASE
CASE 2
blah
ENDCASE
CASE 3
blah
ENDCASE
ENDSWITCH

What I'm saying here is that instead of looking for an ENDCASE to end the 'block', look for a CASE or ENDSWITCH statement, like this:

Switch 5
CASE 1
blah
CASE 2
blah
CASE 3
blah
ENDSWITCH