Post by: BenJeremy on February 10, 2004, 05:26:00 PM
Yeah, it's the TiVo skin running behind it.
Buttons, Radiobuttons and Checkboxes all work so far, soon to have a few more goodies, then the WIP testers can hammer on it.
This is the file being loaded in:
| CODE |
The action script currently driving it:
| CODE |
OnEvent EventHandler LoadDialogFromFile MyDialog TestDialog.xml ExecuteUIOBject MyDialog QUIT :EventHandler ; No code here yet... |
Post by: simbot82 on February 10, 2004, 05:59:00 PM
Cheers Ben J
Post by: Corspegrinder99 on February 10, 2004, 06:14:00 PM
Post by: koldfuzion on February 10, 2004, 06:14:00 PM
heheh. I would tell you thats impressive, kicks ass, totally rocks or is truely amazing.. but you already know that.
So i'll just say, "Nice Work"
Post by: Yuyu on February 10, 2004, 06:34:00 PM
| QUOTE (koldfuzion @ Feb 10 2004, 10:14 PM) |
| Can we get a Google Toolbar with Auto-MXM Form Filler too? heheh. I would tell you thats impressive, kicks ass, totally rocks or is truely amazing.. but you already know that. So i'll just say, "Nice Work" |
My simple but effective reply: What he said ^^^^
Post by: geniusalz on February 10, 2004, 06:51:00 PM
Fonts look very clean (antialiasing?)
Post by: koldfuzion on February 10, 2004, 07:12:00 PM
| QUOTE |
| <Control Type="listbox" CtrlID="106"> <rect t="70" l="210" b="200" r="400" /> <Item> <Text>Item 1</Text> <Selected>True</Selected> </Item> <Item> <Text>Item 2</Text> </Item> <Item> <Text>Item 3</Text> </Item> <Item> <Text>Item 4</Text> <Selected>True</Selected> </Item> <Item> <Text>Item 5</Text> </Item> <Item> <Text>Item 6</Text> </Item> </Control> |
Just testing for duplicate selected items (Bold)? .. is this why no text is showing in the listbox? Because 2 are selected instead of one? Or was the screenshot a earlier capture?
Post by: BenJeremy on February 10, 2004, 07:34:00 PM
| QUOTE (koldfuzion @ Feb 11 2004, 12:12 AM) | ||
Just testing for duplicate selected items (Bold)? .. is this why no text is showing in the listbox? Because 2 are selected instead of one? Or was the screenshot a earlier capture? |
Some aren't done yet... Listbox and Treeview are not there yet, and EditSingle is render-only (I'll detect a keyboard and dynamically pop the VK if one isn't hooked up - it will pop up on the top if the edit box is toward the bottom, on bottom if the edit box is on the top half)
The listbox will optionally handle multiple selections.
I just updates the screenshot (Refresh to get the latest in the first post). There's still clean up to do on the other items. I just added the "CLICK" event for buttons and checkboxes.
Post by: koldfuzion on February 10, 2004, 08:04:00 PM
I think 'm going to patent an "Anykey" Xbox controller that also has a trackball in place of the X logo now.
Post by: flattspott on February 11, 2004, 07:55:00 AM
Post by: BenJeremy on February 11, 2004, 09:16:00 AM
| QUOTE (-FourDoor- @ Feb 11 2004, 01:05 PM) |
| The way I think I see it is that the user have the ability to scroll up and down through the different elements and then push a button to activate the associated event or input using the virtual keyboard? |
Yes, that is correct. What you don't see is the List Box and TreeView controls. There will also be a few others, like image and static boxes.
The virtual keyboard will be used when a real keyboard (or if numeric, an IR remote) is needed to input something into a control, unless the "real" device is present. Even if a keyboard is plugged in, you'll be able to switch over to a virtual one easily enough.
Moving between items will be fairly simple. In most cases, left and right will do the trick - up and down will often work as well. I haven't settled on navigation yet, and with the input system, just about anything is possible.
It's the Xbox equivalent of a Windows dialog, optomized for gamepad usage.
Since the dialogs can be handled by ActionScripts, a complete configuration system can be set up, as well as Wizards that make complete setups very easy for a user.
This is more than a brute force approach to a UI; it's an integrated part of a system.
Tonight I'll post an image of the Virtual Keyboard in action with the single line input.
Post by: Yuyu on February 11, 2004, 09:43:00 AM
A save game manager can be built with it, if an actionscripter puts enough effort into it...
A file manager can easily be built with this as well, again if an actionscripter puts enough effort into it...(not sure if the zip,unzip, and unrar are suported r will be her yet)
And not only as you can see can it look good with text but, it can look very very slick with static images and other concepts...
I mean if someone puts forth the effort and takes it in the right direction this UI unlocks the possibilities of the ultimate file manager with built-i save game support, or you could build them seperately as I said above...
Obvious other uses would be an internal menu system and configuration mangaer that once built could become apart of the internal.xml that is built into the mxm .xbe file...
OMG, the possibilities.... too many to list, but I hope this gives some people better idea of how this is going to put MXM on a plateau that will be hard to reach...
I mean basically everthing with this new UI and actionscripting could lead to "programs" that are run with MXM actionscripting, such as in the future, a BIOS manager, a backup program for backing up games to the HD, and so many other ideas running through my head right now, that I must stop here and just take a minute to ponder the possibilities....
BJ you fu#in rock dude...
On a side note: BJ is there a way you can make the save game for MXM show up as "MXM application launcher" or somethin like that, it shows up as Unknown application in the save manager of M$ Dash, and other dashes show up with there respective names... Just wondering, as it is obviously not that important at all...
Post by: flattspott on February 11, 2004, 09:57:00 AM
Post by: chilin_dude on February 11, 2004, 09:57:00 AM
T.I.A
Post by: BenJeremy on February 11, 2004, 10:19:00 AM
| QUOTE (Yuyu @ Feb 11 2004, 02:43 PM) |
| A save game manager can be built with it, if an actionscripter puts enough effort into it... A file manager can easily be built with this as well, again if an actionscripter puts enough effort into it...(not sure if the zip,unzip, and unrar are suported r will be her yet) |
The Zip, UnZip and UnRar code are currently compiled as part of the MXM build - what I need to do is create a unifying object and set up the API to use it in ActionScript.
| QUOTE |
And not only as you can see can it look good with text but, it can look very very slick with static images and other concepts... I mean if someone puts forth the effort and takes it in the right direction this UI unlocks the possibilities of the ultimate file manager with built-i save game support, or you could build them seperately as I said above... |
With context menus, Save Game management should be a snap.
Actually, the sorts of things ActionScripters are ALREADY DOING are simply amazing, and adding a full UI and the new commands and structured language features, the power of ActionScripting will increase by an order of magnitude or more. For those wondering what's currently available, or what will soon be available, check out the MXM ActionScript forum here. If you haven't, you are really missing out on some cool stuff.
| QUOTE |
On a side note: BJ is there a way you can make the save game for MXM show up as "MXM application launcher" or somethin like that, it shows up as Unknown application in the save manager of M$ Dash, and other dashes show up with there respective names... Just wondering, as it is obviously not that important at all... |
I'll look into it, particularly with the use of a new logo. Part of a general clean up I'll be able to do while the WIP crowd takes control of the System UI and builds some awesome scripts.
Post by: chilin_dude on February 11, 2004, 10:39:00 AM
Post by: BenJeremy on February 11, 2004, 03:51:00 PM
Post by: flattspott on February 11, 2004, 03:56:00 PM
Post by: BenJeremy on February 11, 2004, 04:06:00 PM
| QUOTE (flattspott @ Feb 11 2004, 08:56 PM) |
| Wow, really cool, Correct me if I'm wrong, but by the look of those pics. it would appear that the VirtualKeyboard is positionable (top or bottom of the screen). Also, is that the way the radio button look on an actual tv too? Kinda jagged? I'm not complaining just wondering |
Position depends on the control's location on the screen. If the edit control is in the top half, when it gets the focus, the keyboard is positioned at the bottom - and vice-versa.
As for the look, why not get the updated WIPs and find out?
Still rough edges on the stuff that's there, but I wanted to get them out for you guys.
Post by: flattspott on February 11, 2004, 04:10:00 PM
Post by: BenJeremy on February 11, 2004, 04:14:00 PM
| QUOTE (flattspott @ Feb 11 2004, 09:10 PM) |
| So it's a dynamic Keyboard of sorts. No user intervention needed to put it in the right spot. The cool just keeps getting cooler. |
Well, even better, it only pops up if there's no keyboard (or in numeric cases, IR Remote) available... in those cases, it's still available, but you'll have to invoke it with the Virtual Keyboard button combo.
Like I said in the release thread, there are still a lot of rough edges, but it's far enough along for you guys to start playing with (as well as let me know the buggy parts)
Post by: flattspott on February 11, 2004, 04:29:00 PM
EXEC C:\AUDIO\TEST.XBE is this why?
Post by: BenJeremy on February 11, 2004, 04:32:00 PM
| QUOTE (flattspott @ Feb 11 2004, 09:29 PM) |
| Okay after I run it, (the testscipt) right after the LoopTest 7 part I get an error at Line 25. EXEC C:\AUDIO\TEST.XBE is this why? |
That's because there is no file.... unintentional side effect of my not cleaning up the test script before the update.
What do you think about the dialog?
Post by: geniusalz on February 11, 2004, 05:22:00 PM
Few thoughts:
Don't make the keyboard popup on focus. Instead, when a textbox gets focus, draw a rectangle round it, like you do with the rest. When someone presses A on it, the keyboard can popup. Pressing B should hide the keyboard (unless it does something else)
Radio buttons are working weird. All three are 'checked' at once first time the script is run, and clicking any of them and rerunning the script does weirdness to the checking. Sometime just rerunning the script and exiting a few times causes them to check/uncheck randomly.
Post by: BenJeremy on February 11, 2004, 05:31:00 PM
| QUOTE (geniusalz @ Feb 11 2004, 10:22 PM) |
| Pretty cool Few thoughts: Don't make the keyboard popup on focus. Instead, when a textbox gets focus, draw a rectangle round it, like you do with the rest. When someone presses A on it, the keyboard can popup. Pressing B should hide the keyboard (unless it does something else) Radio buttons are working weird. All three are 'checked' at once first time the script is run, and clicking any of them and rerunning the script does weirdness to the checking. Sometime just rerunning the script and exiting a few times causes them to check/uncheck randomly. |
On the radio buttons.... that's a clean up issue. That will be fixed in the next update.
As for the VK activation.... RT-Trig+Y will toggle the virtual keyboard, and I see what you are saying about only activating it when somebody "selects" the keyboard. I'll have to consider that; it might require me to remap some stuff. To be honest, I've set up things to handle multiple key maps, but I just haven't gotten around to wrapping up the details and creating new maps.
(Now get back to cramming for those tests tomorrow)
Post by: Kthulu on February 11, 2004, 06:40:00 PM
looks like these new controls will make alot things easier to implement in actionscripts and prettier in code and in visual effect on the screen. however, i think on-screen prettiness could really be boosted by the ability to do text auto-sizing like in skins. any chance of that?
also, will we be able to do something like this?
| CODE |
set myTop 10 set myText "Static Text" |
Soon, you will have access to the XML, and there is a "reconfigure" capability in the code - change the setup XML and reconfigure, and the display should change.
Post by: geniusalz on February 11, 2004, 06:44:00 PM
Post by: flattspott on February 11, 2004, 06:46:00 PM
Post by: Kthulu on February 11, 2004, 07:06:00 PM
| QUOTE |
| You could probably add that node to the xml, and then redraw the dialog using that. |
ah, i see. i missed this before...
| CODE |
| OnEvent EventHandler LoadDialogFromFile MyDialog TestDialog.xml ExecuteUIOBject MyDialog QUIT :EventHandler ; No code here yet... |
wheww...i was starting to think that we had lost some power in the process of trying to simplify things.
so now i'm wondering/hoping we can load dialogs from xml in memory and that it doesn't have to actually exist in a file...???
Post by: flattspott on February 11, 2004, 08:48:00 PM
| CODE |
| Because dialogs are created using XML, it should be trivial to either use a prebuilt dialog or dynamically create your own dialogs as needed |
from the UI Spec White Paper
Post by: Kthulu on February 11, 2004, 09:25:00 PM
| QUOTE (flattspott @ Feb 12 2004, 12:48 AM) | ||
from the UI Spec White Paper |
Yesss...we're gonna hold you to that BJ
Post by: BenJeremy on February 12, 2004, 01:19:00 AM
| QUOTE (flattspott @ Feb 11 2004, 11:46 PM) |
| How do we go about using the Dialog elements: like the test button for example. What needs to be done to get it to to do some something? Are we spose to use something like IF CrtlID{101} == "1" GOTO Oh, yeah the dialog looks pretty great for being newborn and all |
In the event handler, you can use a switch statement:
| CODE |
:EVentHandler SWITCH %UIObjectHandle% CASE MyDialog ; Now look at the control id (UITriggerID) SWITCH %UITriggerID% CASE 1 SWITCH %UIEventID% CASE 1 ...SOMECODEHERE... ENDCASE ENDSWITCH ENDCASE ENDSWITCH ENDCASE ENDSWITCH |
It doesn't have to be that complicated, depending on how you number your controls (if you number them all uniquely, even among different dialogs, you could skip the UIObjectHandle stuff.)
Another technique might be to put a LABEL in the XML of the dialog controls to handle specific control's events, and extract that.
Post by: BenJeremy on February 12, 2004, 01:21:00 AM
| QUOTE (Kthulu @ Feb 12 2004, 02:25 AM) | ||||
Yesss...we're gonna hold you to that BJ |
Yes, I fully intend on expanding the methods for submitting dialogs. The CreateDialog method will be set up to use the node location given with an XML handle.
Likewise, I was thinking last night of adding the ability to create an XML handle from a UI Object handle, or even making them interchangable.
Post by: flattspott on February 12, 2004, 03:47:00 AM
The SWITCH stuff is sort of like the IF stuff only instead if having just 2 IFs (ELSLIF) you can use however many CASEs you need. So basically the SWITCH will go through all the CASEs until it finds the appropriate one to use based on the current variable?
Post by: BenJeremy on February 12, 2004, 04:48:00 AM
| CODE |
SWITCH %SomeVar% CASE 1 MsgBox "This is displayed when SomeVar == 1" ENDCASE CASE 2 MsgBox "This is displayed when SomeVar == 2" ENDCASE CASE 3 CASE 5 MsgBox "This is displayed when SomeVar == 3 and SomeVar == 5" ENDCASE DEFAULT MsgBox "This is displayed when SomeVar equals something else not covered above" ENDCASE ENDSWITCH MsgBox "Code continues here after the ENDCASE statements!" |
They can be nested, too.
Post by: flattspott on February 12, 2004, 05:04:00 AM
| QUOTE |
| SWITCH %SomeVar% CASE 1 MsgBox "This is displayed when SomeVar == 1" ENDCASE CASE 2 MsgBox "This is displayed when SomeVar == 2" ENDCASE |
Ok but what about in dialog use. Cause in your TestDialog, you have CtrlID="101"
Should we then do it this way
CASE 101
MsgBox "This is displayed when SomeVar == 1"
ENDCASE
CASE 102
MsgBox "This is displayed when SomeVar == 2"
ENDCASE
Post by: BenJeremy on February 12, 2004, 05:07:00 AM
| QUOTE (flattspott @ Feb 12 2004, 10:04 AM) | ||
Ok but what about in dialog use. Cause in your TestDialog, you have CtrlID="101" Should we then do it this way CASE 101 MsgBox "This is displayed when SomeVar == 1" ENDCASE CASE 102 MsgBox "This is displayed when SomeVar == 2" ENDCASE |
Yes, whatever values you use in CASE are intended to match up to the value following the SWITCH statement.
The value following a CASE can be anything, even text. There's also a numeric comparison version.
I added it specifically to handle events from the dialogs, though it has many more uses.
Post by: flattspott on February 12, 2004, 05:30:00 AM
Another thing (TestDialog) you have
<rect t="10" l="10" b="30" r="100" />
<Text>Test</Text>
<rect t="50" l="10" b="70" r="100" />
<Text>Exit</Text>
Onscreen they both look the same size but the B values are different. How's that work. Is it like B is the bottom edge of the Box in relation to the top of the screen?
Post by: BenJeremy on February 12, 2004, 05:52:00 AM
| QUOTE (flattspott @ Feb 12 2004, 10:30 AM) |
| Ok cool, I think I'm getting it now. Another thing (TestDialog) you have <rect t="10" l="10" b="30" r="100" /> <Text>Test</Text> <rect t="50" l="10" b="70" r="100" /> <Text>Exit</Text> Onscreen they both look the same size but the B values are different. How's that work. Is it like B is the bottom edge of the Box in relation to the top of the screen? |
rect
l = left
r = right
t = top
b = bottom
In relation to the dialog window...
I'm restricting the methods for setting position because I figured ActionScripters won't be as sloppy as other users
otherwise, I'd have included width and height.What we need is a handy-dandy dialog designer.
Post by: Yuyu on February 12, 2004, 06:24:00 AM
| QUOTE (BenJeremy @ Feb 12 2004, 09:52 AM) |
| What we need is a handy-dandy dialog designer. |
Hey Geniusalz, please, get your a$$ over here and get us a dialog designer...
Well after your mid-terms are over of course (mine start next week)
Post by: geniusalz on February 12, 2004, 07:56:00 AM
Post by: flattspott on February 12, 2004, 11:19:00 AM
Post by: geniusalz on February 12, 2004, 12:32:00 PM