Print

[corin415]

um ya im not good with words so here is a crude drawing............

[orangerhino]

Could you put the ability to make passwords for Files/Folders, so that not just anyone could go through everything on your hdd?

[koldfuzion]

How about a file manager that actually displays icons depending on file/content  type.   If not a predefined file type,  then just show a default/generic icon.

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.

[Jezz_X]

I quite like the boxplorer has the keys set up but as for dual or single pain as long as the text is readable from the full length of the controller cable I dont care

[BenJeremy]

Well, you all can play with the ListBox control now.

1185 is now available for WIP testers.

[flattspott]

[BenJeremy]

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.

[BenJeremy]

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.

[flattspott]

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.

[BenJeremy]

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.

[geniusalz]

How about re-populating skins whenever the user goes into the skin selection menu?

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)

[Kthulu]

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?

[BenJeremy]

Well, no to put you off, Kthulu, but there are a couple of practical problems that crop up with those well thought and excellent suggestions...

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.

[Kthulu]

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???

[LarryX]

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