Post by: BenJeremy on February 27, 2004, 07:42:00 PM
This weekend, I may be able to wrap up the List Box control.
Obviously, we need to discuss basic functionality. I'm thinking a list box and a viewing pane, unless in copy/move mode.
Discuss some ideas here.... I want to cover all the bases (in a practical manner) so anything still missing can be implemented. <
Post by: Kthulu on February 27, 2004, 07:54:00 PM
also, since they are very similar, it would be nice if the official file manager had a couple of modes whereby it could replace my fileOpen.xas script. one mode/use would be to select a file, while another mode/use would be to select a directory, and then, of course, a 'file manager' mode for copying, deleting, moving, renaming, etc. with some degree of context-awareness where an xbe or xas could be launched from the file manager.
This post has been edited by Kthulu: Feb 28 2004, 03:59 AM <
Post by: BenJeremy on February 27, 2004, 07:59:00 PM
| QUOTE (Kthulu @ Feb 27 2004, 11:43 PM) |
| can you help me understand what you are thinking with the list box/view pane there? is that like where the listbox only contains directories, while the viewing pane contains the files within the directory selected in the listbox? |
The listbox would navigate much the same way you do when using FTP - At the top level, you'd see a list of available drives. At the top of each folder (except the root), you'd see ".." to carry you to the next higher folder level.
Directory names might be followed by <DIR> or something similar. <
Post by: Kthulu on February 27, 2004, 08:02:00 PM
| QUOTE (BenJeremy @ Feb 27 2004, 10:48 PM) | ||
The listbox would navigate much the same way you do when using FTP - At the top level, you'd see a list of available drives. At the top of each folder (except the root), you'd see ".." to carry you to the next higher folder level. Directory names might be followed by <DIR> or something similar. |
sorry, but i'm still not understanding this:
| QUOTE |
| I'm thinking a list box and a viewing pane, unless in copy/move mode |
the listbox would show the files/directories, but what would the viewing pane show?
PS. did you see my edit of my previous post?
This post has been edited by Kthulu: Feb 28 2004, 04:02 AM <
Post by: BenJeremy on February 27, 2004, 08:08:00 PM
Since I plan on having a multi-select in the list box, we will be able to "mark" multiple files for a copy, delete, or move operation.
So what operations do we have so far:
Copy
Move
Delete
Execute (XBE/XAS)
View
Install (XBE or XAS to menu, if not already in the menus)
Rename
Rename XBE Title
Media Patch
Live Patch
Edit Games DB Entry
- Title
- Desc
- Select Thumb
- Select Preview
...and so forth....
<
Post by: Kthulu on February 27, 2004, 08:12:00 PM
Operation:
Auto-add Directory (would add the directory to the menu 'autodir' style)
<
Post by: Kthulu on February 27, 2004, 08:24:00 PM
Operations:
Edit Games DB Entry
-Add Custom Tag
maybe?
EDIT: oh yeah, and on the Execute operation...
perhaps have the ability to maintain a file somewhere of file associations so that txt, ini, xml, etc files could be launched by a text editor :) and hopefully, in the future, mpg, avi, etc. could be 'associated' with the user's media player.
something like:
FileAssociations.xml
| CODE |
.txt c:\mxm\scripts\texteditor.xas .mpg f:\apps\xbmc\default.xbe .nes f:\emulators\fceultrax\default.xbe |
This post has been edited by Kthulu: Feb 28 2004, 04:30 AM <
Post by: boomboom on February 27, 2004, 08:26:00 PM
Post by: BenJeremy on February 27, 2004, 08:30:00 PM
Now I've got to hit it. It was a very long day. :huh: <
Post by: flattspott on February 27, 2004, 08:41:00 PM
<
Post by: flattspott on February 27, 2004, 08:52:00 PM
And adding to this idea. There could also be some special type of file that could loaded into a listbot that would show the full file name while the real file is FatX compliant. Like GBA roms
You could have an XML or something.
This is would it be for if you had a GBA Rom
<Rom File="0001.zip" >F-Zero for Gameboy Advance</Rom>
etc <
Post by: Kthulu on February 27, 2004, 08:55:00 PM
| QUOTE |
| Consider execution, as well... I can map keys for some functions, but others will have to be put into a popup context menu |
if you're worried about fitting all those menu items on the screen at once...don't :)
have layered menus...in other words, a main menu that is context sensitive and then submenus
<
Post by: flattspott on February 27, 2004, 08:56:00 PM
The left side would work as normal, the right side would be autofilled with the gamesave folder. <
Post by: geniusalz on February 27, 2004, 10:01:00 PM
Post by: Yuyu on February 27, 2004, 10:12:00 PM
This post has been edited by Yuyu: Feb 28 2004, 06:14 AM <
Post by: corin415 on February 27, 2004, 10:36:00 PM
Post by: orangerhino on February 27, 2004, 10:39:00 PM
Post by: koldfuzion on February 28, 2004, 06:14:00 AM
ZSM, ZSK, XAS <<-- MXM Specific
XBE, XML, WMV, AVI, MPG, BMP, JPG, PNG,
etc, etc
and like corin415 shows in his drawing.. regular folder icons too.
Post by: Jezz_X on February 28, 2004, 08:51:00 PM
Post by: BenJeremy on March 02, 2004, 06:17:00 PM
1185 is now available for WIP testers.
Post by: flattspott on March 02, 2004, 06:38:00 PM
Post by: BenJeremy on March 02, 2004, 06:58:00 PM
| QUOTE (flattspott @ Mar 2 2004, 11:38 PM) |
| Cool. I've been waiting for the ListBox to come. |
You should be able to interact with it using the click event. It will do multi-select at the moment, but I'll add something to restrict that, in the next release.
Post by: BenJeremy on March 04, 2004, 11:16:00 AM
OK. Skins.
My vision:
On startup (at various points in initialization):
| CODE |
MXM loads Prefs MXM Scans Plugins for ZSK files, unpacks new files to SkinsPath - MXM adds each NEW skin to the Active Skins List. MXM Scans Skins Path for new skins - MXM adds each NEW skin to the Active Skins List. MXM Selects skin to load MXM loads XML MXM Executes SkinLoad Plugin Script MXM Initializes Skin |
Selecting skins is a bit more detailed:
| CODE |
IF SkinSelectMode == Single Select Named Skin ELSE IF SkinSelectMode == Random Select Skin from Acive List (except for last skin, unless only one skin is on list) ELSE Select Next Skin on Active Skin List after Last Skin Loaded |
Now we get more tricky... I'd like some suggestions on this. CONFIGURING the skins. There will be a master list of skins from the SkinsPath (and internal skins). From this list, you can either 1) Pick a single skin to use, 2) Pick a list of skins to either randomly or sequentially display.
How should this be handled in a dialog or dialogs? I have some ideas, but there are several ways of doing it. I'd like to hear yours. Obviously, we use a ListBox to display the available skins. Radio buttons to select the mode. A Preview image/video is a must. What else?
Try to think of the easiest, handiest way to do this. We might also want to be able to "uninstall" (i.e. delete) skins and maybe validate them, list info/resources, etc...
This will eliminate the current skin settings (Internal toggle and skin picker). I will also be looking at making the skins available without a reboot.
Post by: flattspott on March 04, 2004, 11:38:00 AM
And I came across a problem in the listbox (your test dialog)
I was browsing around the drive clicking on things to view. Whenever I clicked on about 5 or 6 images it, (the listbox) sort of freezes up. Not completly but almost. You can still jump to the other controls.
Post by: BenJeremy on March 04, 2004, 12:05:00 PM
| QUOTE (flattspott @ Mar 4 2004, 04:38 PM) |
| Sorry but I'm all out of ideas at the moment. Maybe later I'll have some though, after I let my mind percolate this. And I came across a problem in the listbox (your test dialog) I was browsing around the drive clicking on things to view. Whenever I clicked on about 5 or 6 images it, (the listbox) sort of freezes up. Not completly but almost. You can still jump to the other controls. |
Strange... I'll take a look. I can't imagine what might be happening there, unless there's some sort of memory leak or something going on.
Post by: geniusalz on March 04, 2004, 01:41:00 PM
As for deleted skins, I guess on startup, MXM could just remove the skin from the active list, and look for another skin.
What about manually added skins and manually deleted skins? Shouldn't it do a dir listing? (but that will add to the load time)
Alternatively, MXM could select the next random skin AFTER startup. It would then write the skin name and path to the prefs.xml file, and on the next startup, would load that skin, and put another into the xml. This would cut down on some initialization time (scanning skin dir's/unpacking)
Post by: Kthulu on March 08, 2004, 09:17:00 PM
| QUOTE |
I have some ideas for this, but I'd really like to release "O" before pursuing them - so feel free to discuss some ideas here, just remember I'm on track to get a new release out with the primary goals of a decent File Manager and Easy Configuration. |
Easy Configuration...
I'm under the impression that this will mostly be driven by actionscript. However, whenever I think of ways to do this with actionscript, I keep running into 2 obstacles. Here they are...
1. System Configuration settings are in MXM.XML and E:\udata\00004321\pref.xml
Suggestion: Consolidate configuration information into one file. MXM.XML seems the best choice to keep multidisc happy.
2. Menu Configuration ambiguity
Example:
<submenu>
<title>Games</title>
<description>SubMenu</description>
<sortfield>title</sortfield>
<item>
<autodir Flatten="true" NoDemo="true" DefaultOnly="true" Recurse="false">f:\games</autodir>
</item>
</submenu>
Every item must be checked to see if it is an actual item or an auto-directories.
Suggestion: The <autodir> tag doesn't seem happy where it lives
Seems like it should be a sibling of <item> instead of a child. I think it would be happier here...<submenu>
<title>Games</title>
<description>SubMenu</description>
<sortfield>title</sortfield>
<autodir Flatten="true" NoDemo="true" DefaultOnly="true" Recurse="false">f:\games</autodir>
<item>
...item stuff...
</item>
</submenu>
This way, you only need to check the submenu for auto-directories, but you can still have multiple <autodir>'s just like you can have multiple <item>'s
what do you think, BJ?
Post by: BenJeremy on March 09, 2004, 01:37:00 AM
On the MXM.xml vs. prefs.xml issue, prefs.xml are never intended to be hand-edited. MXM.xml is intended to be strictly for the multi-app DVD-R mode crowd, eventually (as it originally was, too). I'm trying to move AWAY from using that file at all in dash mode. All settings inthe MXM.xml will migrate to the prefs.
Why prefs in a standard, common directory? Because even when user's customize DVD-R menus, they may want to override some options when loading those discs. In those cases, some settings in particular would be used to override key settings at the user's request (such as music settings).
I'm open to changing some of the settings, particularly the overrides, provided they maintain compatibility with older versions of MXM, for those who've burned discs up to this point.
As for the AutoDir, that's tricky. AutoDir tags are typically done as Eleemnts in most menu.xml files.... and it's much more difficult to parse in order when there's a mixture of nodes and elements to scan; I do not keep the order internally beyond those groupings - i.e. I have order within elements, and withing node,s but not between them. This would severely change the way ordering is performed by a user.
On both counts, I think a well-set UI will eliminate these as concerns though. Realistically, the user never has to hand-tweak either file (prefs.xml and menu.xml) and even for DVD-R operation, config and menu creation apps will ultimately provide more accurate handling of the duties. For "Easy Configuration" that is exactly what I intend to do - make it easy to configure without having to touch a single setting manually.
Post by: Kthulu on March 09, 2004, 04:51:00 AM
it still seems to me that <autodir> would be better as a sibling of <item> (as a node instead of an element) but i guess that would take alot of work.
EDIT: or maybe i did my <autodir> wrong in my menu file???
Post by: LarryX on March 09, 2004, 05:43:00 AM
| QUOTE |
| EDIT: oh yeah, and on the Execute operation... perhaps have the ability to maintain a file somewhere of file associations so that txt, ini, xml, etc files could be launched by a text editor and hopefully, in the future, mpg, avi, etc. could be 'associated' with the user's media player. |
It's inevitable that once you associate a file with a program you will want to open that file with a different program. That is where 'Open with...' comes in. And then again it may be easier just to use an 'Open with...' menu
Post by: BenJeremy on March 09, 2004, 07:36:00 AM
| QUOTE (Kthulu @ Mar 9 2004, 09:51 AM) |
| i completely understand why prefs.xml is the better choice after you explained. the important thing to me was that settings and config info be consolidated and it sounds like you were planning on that already. it still seems to me that <autodir> would be better as a sibling of <item> (as a node instead of an element) but i guess that would take alot of work. EDIT: or maybe i did my <autodir> wrong in my menu file??? |
Well, the XML parser I have heavily modified and incorporated considers any tags that have other tags in them to be "nodes" - while those simply having values are "elements". I designed the API I use to rather loosely handle values whether they are elements or attributes, and even handle specific elements of node ("value") as values of a node identifier.
In short, I designed it to be very forgiving of human-written XML input.
To this end, Items almost always nodes, though it might be possible to put a monkey wrench in things and define all of the values as attributes. AutoDir, on the other hand, is very easy to define as an element, since it has few "subvalues"
:::shrug::: if I had to do it all over again, I would not have made a distinction between nodes and elements at all. My next project will probably utilize a parser and data access API I write from scratch.
Unfortunately, that terrible word "legacy" pops up to bite me in the ass now. Making significant changes to make AutoDir work as you say, would likely break a great deal more things.
Trust me, though... were I writing this from scratch, I would do things differently (probably more along the lines of your idea).