Minimenu And Tool Changes.. Rfc :)

[skeezix]

(RFC being 'request for comment.)

Theres a million things we'd all like to do in the firmware; this is not to discuss that. We know, but we only have a couple hands at it

Or should minimenu just stay as it is, nice and 'simple' (its already pretty flexible)? It may not please everyone, but the goal was simple to use, and simple consistent default setup.. not to please everyone, but to just work. Should we leave it alone, or grow it?

Still, a few suggestions seem to come up (mostly from DaveC), but a few I've onserved over the months... hence things I've been working on and considering; any problem with the below, let me know

- currently (to avoid making too much work for skinners) minimenu uses 'info panel' on the 'right' for menus; add a basic dialog box renderer to minimenu so it can do popup menus instead; a bit more work for all existing skins, but gotta push for it sometime. This sort of frees me up to do a few things without being 'stuck'.

- switch 'Select' menu to dialog box instead of living in the right side info panel; implication -- the info panel is _always info_ then, instead of sometimes being info, sometimes being a menu.

- add some menu items (context dependant) and re-arrange the select menu. ie: if an item is selected, and menu is brought up, could offer a 'delete this app' option, or 'hide this app'. (Delete I've avoided since you might have 5 apps in one pnd, and deleting it deletes all at once. Most pnds are a single app, so it makes sense there. As a workarond, when hitting Delete, could show a list of impacted apps in confirmationdialog..);
- for re-arrange, need to consider .. select menu to do config and global changes, and X or something to pop up item menu with Toggle Info Panel, Delete pnd, Change preferred cpu speed, Hide app, stuff like that. Need to review all the options and mull it over still. (minimenu was meant to be simple and not too configurable, but seems we've got a lot of people who want it to be configurable and complex)

- now that the info panel is purely info panel and not menus for random things, can make it togglable; maybe changes to skins to support this effect, but I'm thinking about something like .. default to info panel on, but allow alt-f or Y or something to toggle it on and off, with the goal of letting you have a full screen of icon grid if you want it. Another option is to make the info panel cease to exist entirely, and just make it a hovering panel (either locked in place or even movable with drag and drop but mostly just a pop up when needed thing) -- ie so you could summon the info panel and then dismiss it; I dislike hovering panels since it implies _Covering_ stuff, and is lots of UI rework. (Remember, minimenu was originally written pretty quick, so its not the most architecturally awesome piece of code So all told, I'm thinking of just toggling between two modes -- info panel on, and info panel off, and each skin would really branch into two skin-configs maybe (one for each mode), or something. For toggling .. 'Y' currently goes to Help/Documentation for a given pnd, but it occurs to me we coudl have Y toggle info panel on and off, and a menu item to bring up the Help (though that puts the help a few steps removed, peopel dont' use it all the time after the first look I imagine, so maybe thats okay.)

- a new option in the config panel that could be enabled; "intuit tab from directory structure" (ie: insetad of pullign categories from PXML and then using categories for tabs, you could eelct to file the apps to tabs entirely yourself, using directory structure.) This would be 'last step in the chain of decisions' so would override everything (ie: PXML first, then ovr file overrides that if present, then this.) The way this would work is still to be nailed down (since its a fuzzy thing), but I was figuring something like ...
- a second option that only is used if the first option (intuit tab from dir struct) is used "allow subcategories as well".
For any given search path entry (such as /pandora/menu, but there are others and you can change the searchpaths all you want of course, if you're a config spelunker), make directory contained within imply category; if the second option is set as well, then _Two directories_ are used (so you can have subcat.)
Implication -- an app now has a single category per pnd file (normally PXML can imply multiple categories per app); also, a pnd file may have multiple apps within, so this rather implies the tab for all of them.
Example: Currently you make /pandora/menu/foo.pnd (or even /pandora/menu/bar/foo.pnd) and the PXML (and optional .ovr file) specify the categories and thus tabs
-- currently you can hide/show the app or tabs from the menu, of course

Example: Turn on this option (intuit from dir structure), and then /pandora/menu/bar/foo.pnd implies that all apps within foo.pnd are in tab called 'bar'. Thats it. Suddenly you use drag and drop in windows or the dir browser on device to specify tabs. (for minimenu, ignored by xfce etc, which would use PXML/.ovr files as normal.)
Example: If option is on, and pnd file is in /pandora/menu/foo.pnd (not in a subdir of the searchpath), then PXML/.ovr-file category would be used as normal (since nothing is implied by dir structure location.) ie: 99% of people don't know they can subdirectory pnd files within a searchpath, so their stuff is in /pandora/menu or /pandora/desktop or whatever .. so turning on the option wouldn't _break anything_, which seems ideal
Example: If option is on, and the second option is also on, then you coudl do .. /pandora/desktop/bar/subdir/foo.pnd to imply that foo.pnd is in both 'bar' and 'subdir', and then use tabs for both (disabling as you see fit in the config menu of course.)

So essentially, we'd have a option or two, that are globally effective; if you want to specify category by dir structure, then you do it as either single-category, or cat+subcat, for all tabs. Not 'some tabs have subcats, others don't; but you can easily hide/show tabs in the config panel already, so I figure no biggy; I imagine most people would just pick the first option and categories apps to a single tab, and not worry about subcats. (ie: or maybe Games, and Games with subcat Emu's, perhaps.)

- a new option in config 'keep appdata with pnd-file'; when turned on .. if you have /pandora/desktop/bim.pnd, then it would put appdata in /pandora/desktop/bim-1234/ instead of /pandora/appdata/bim-1234; note that the user woudl be responsible for relocating any existing appdata to the new location on his own.

- I've been debating a 'ovr editor' since no one knows about ovr's excdept the 5 people who looked closely at the wiki But with options above to specify category in alternate ways, it might confuse people; still, ovr's override PXMLs in a pnd, and are useful for minimenu and xfce and any other desktop, so they have a place. ovr's let you override the cpu-speed preference of an app, its advertised categories, the name of the app, a few things like that. An ovr editor (since it works for all environments) woudl probabyl be a tiny standalone dialog box based app, which would look goofy when run from minimenu, but such is life (unless I write everything twice, and who has time for that?) Alternatively, I could just put a 'cpu speed editor' into minimenu, since thats really the option people woudl mess with, I bet. As a separate app, anyone can do it, and I can atleast od it separetly to the rest.

- Right now, theres a 'reveal hidden' menu item to show the suppressed tabs; it might be worth changing so that instead of letting you 'bring a hidden tab into the shown tab list', to change the way it works entirely; so only show 'top level tabs', and not show sub-cat tabs at all; then hit the menu item 'drill down', which pops up a list of subcats, and you pick one, and it temporarily shows that one instead. That is goofy from a UI design imho, since look away for 10 mins and look back, and you migjht see only 1 tab and say 'wtf' .. but I could put a note in the tab bar .. show the one tab, and say to the right of it 'we're in drill down mode; hit menu to drill up again' or something. This is why I built it how it is now .. show shown tabs, and then let you reveal a hidden tab idf you like; stil same tab UI, no confusion. But it weirds ED out

- Really low priority, but trivial to implement; a couple people asked if they could have minimenu not quit when an app is run. Thats rrivial to add technically. UI could be work .. could add a global conf item 'keep minimenu up when running apps', and it woudl always be that way. Just shoves minimenu into a window when another app is up, and no app switching/management in minimenu. Another option is when you hit Start or B to run an app, if you hold it down (say), could leave minimenu up, or something. But I'm not sure this option is useful at all (since mm is designed to quit on run, then come back up later)

Discuss.

jeff

 

[skeezix]

tl;dr anyone?

 

[Pleng]

- Really low priority, but trivial to implement; a couple people asked if they could have minimenu not quit when an app is run. Thats rrivial to add technically. UI could be work .. could add a global conf item 'keep minimenu up when running apps', and it woudl always be that way. Just shoves minimenu into a window when another app is up, and no app switching/management in minimenu.

Low priority

Minimenu works really nicely with Matchbox WM & XFCE Panel, but in this configuration it's ALWAYS run in a Window. If it's trivial to implement not quitting then that would really be appreciated, as it finally gives the Pandora the Multitasking, yet mobile oriented interface that it deserves:

Another nice thing would be if 'minimenu' is executed while minimenu is already running, it brings the menu to the front of the screen. That could then be nicely mapped to the home shortcut in the panel to always return you to the menu.

- a new option in the config panel that could be enabled; "intuit tab from directory structure"
...
- I've been debating a 'ovr editor' since no one knows about ovr's excdept the 5 people who looked closely at the wiki But with options above to specify category in alternate ways, it might confuse people; still, ovr's override PXMLs in a pnd, and are useful for minimenu and xfce and any other desktop, so they have a place. ovr's let you override the cpu-speed preference of an app, its advertised categories, the name of the app, a few things like that. An ovr editor (since it works for all environments)
..
- add some menu items (context dependant) and re-arrange the select menu. ie: if an item is selected, and menu is brought up, could offer a 'delete this app' option, or 'hide this app'.

You appear to be approaching 1 issue from about 30 different angles!

Why not have an options menu that comes up when the user presses the appropriate button with the following items:

-Run (why? see below)
-Remove From Category
-Copy to Category
-Move to Category
-Set desired CPU speed (currently.....Mhz)

These options can effectively create or edit OVR files in the background without the user being aware of them. Nobody wants to mess about with text files just to be able to move icons around from one category to another. A couple of little pop-ups, though, that's what people are used to. Things like this need to be as transparent to the end user as possible.

Why have a run option? Well... people press the wrong button by mistake. I was always doing it on GMenu2X then having to remember the button to cancel... so a nice option to simply run the app from the menu you've called up would be fantastic.

What I'd also like to see, later down the road, I suppose... is some kind of Plugin System. Whereby each plugin gets its own tab and x amount of screen space. This would be great for, for example embedding audio/video browsers directly into the menu to really give an integrates feel.

 

[skeezix]

1) I've been debating a tab-plugin system, but wasn't sure if that was 'far enough'; it has been tempting to make the whole render engine a plugin, and then a list of plugins (.so's) to produce a list of applications, and the full plugin wazoo. But that woudl take awhile to re-engineer it.

Making a 'plugin per tab' type plugin system would be relatively easy I think; just define an interface .. a function to render, a function to receive input, a function to return if the tab needs to be forcibly brought to front for some reason, etc. I coudl build that if you like.

2) if its high priority for you, thats fine; its a trivial change at the global level -- new config panel entry (just a line in a struct) and an if-statement in the run-code. Cake.

3) The whole 'whats a tab' issue is reasomably complex; I'd just do PXML or ovr-files myself, but DaveC (and some numebr of his fans like the idea of just drag and drop in the filesystem to assign tabs. But as I noted, thqts just _another_ way to effect a tab assignment, than PXML and ovr. I agree its painful in that having too many systems for the same thing is awful, but if its sufficiently worth it for ease of use, I'm okay with it. But thats why I posted it here -- is it worth it?

4) A 'run option' (so you can cancel it) .. ie: we could maybe do it so 'start' is a "just run it' and 'B' is a 'context menu, including run option', might work; newbies coudl hit Start, others could use B if they prefer the option.


I must admit, working on (1) would be fun and I've toyed with it, just wasn't sure if anyone cared. But as always, you cut right to the meat

jeff

 

[naples39]

Haven't had my Pandora in a while so everything's not fresh in my mind, but I'm all about an ovr editor/maker.

I make ovr's for every pnd I have to set custom folder placement and preferred cpu speed per app. Would be nice to be able to edit that info from within minimenu.

 

[Pleng]

1) I've been debating a tab-plugin system, but wasn't sure if that was 'far enough'; it has been tempting to make the whole render engine a plugin, and then a list of plugins (.so's) to produce a list of applications, and the full plugin wazoo. But that woudl take awhile to re-engineer it.

Making a 'plugin per tab' type plugin system would be relatively easy I think; just define an interface .. a function to render, a function to receive input, a function to return if the tab needs to be forcibly brought to front for some reason, etc. I coudl build that if you like.

I think it would be great. I'd love it.... but I don't have the expertise to do anything useful with it myself... Perhaps in the long, long term you could build in some kind of python (I prefer LUA as I knod of know it, but I'm well aware the language of choice amongst Pandorians is Python) scripting interface? Then some minimenu 'widgets' which could then be rendered with the minimenu's theme in mind.... all this in the long term of course .

I really like the idea of making the rendering engine itself a plugin, that could really up the potential. It would provide potential for the 'list view' mode that Dave dislikes It would also be great for making a 'home' tab, which could be nothing more than a set of links to other tabs.

2) if its high priority for you, thats fine; its a trivial change at the global level -- new config panel entry (just a line in a struct) and an if-statement in the run-code. Cake.

Awesome.

3) The whole 'whats a tab' issue is reasomably complex; I'd just do PXML or ovr-files myself, but DaveC (and some numebr of his fans like the idea of just drag and drop in the filesystem to assign tabs. But as I noted, thqts just _another_ way to effect a tab assignment, than PXML and ovr. I agree its painful in that having too many systems for the same thing is awful, but if its sufficiently worth it for ease of use, I'm okay with it. But thats why I posted it here -- is it worth it?

While I'm a fan of file system level management for my audio and video files... with apps its, from my point of view, a bit much. It also rises the issue of multiple category management. If it's easy enough for you to add, and doesn't interfere with any of the other management solutions then, as you say, 'why not?'. I think it should be burried from the user a little, perhaps in an 'advanced options' menu, though.

4) A 'run option' (so you can cancel it) .. ie: we could maybe do it so 'start' is a "just run it' and 'B' is a 'context menu, including run option', might work; newbies coudl hit Start, others could use B if they prefer the option.

Absolutely. The option wasn't really intended as a 'this is my preferred way to launch apps' method. More of a time and face-saving way out of the 'shit I've pressed the wrong button' situation. Also, of course, if you hand the 'dora to a friend or are showing off, they may instinctively press one of the face buttons. Giving them an option of running from the pop up menu rather than having to cancel and find the right button is just showering them with wonderful HCI

I must admit, working on (1) would be fun and I've toyed with it, just wasn't sure if anyone cared. But as always, you cut right to the meat

jeff

I Totally care and am happy to help out on the theory side of things whenever needed. With the plugin system, Minimenu
can become a complete all-in-one operating environment for the Pandora, with or without multitasking. And that's something a device like this really needs.

 

[DaveC]

Sounds like all of that crap will be a resource hog resulting in slower running emus and long boot times.

Really if we really need all of that stuff why not just run XFCE? You have all the multitasking you want there. You will have users just keep loading things and not realize that they have 10 things running in the background and wonder why they get stuttering and 2 fps in their coleco emu. Also you will have to start managing tasks by manually closing things you don't want to get speed, memory etc. Too much work and fucking around.

The whole idea of this was to get to and load the apps you want quickly, mostly games, emus, etc. If you bloat it up with all kinds of heavy plug in stuff it destroys the point of a quick loader.

Also the problem with just doing tabs the way the PXML is is that the catagories are often retarded (Emulators with "Game" as the main tab, too many games with super detailed descriptions making too many new tabs etc). This is why the directory method was mentioned, then you can make them show up where you want without hassling around with hacking .OVR files.

 

[DaMummy]

wait so....the minimenu be a pnd itself?...as in loading the minimenu as an app while youre in xfce?

 

[skeezix]

DaMummy -- no; no idea where you got that idea from OR if you got that from Plengs post then .. what Pleng is doing is running minimenu polus the window manager and some accessories from xfce, but that will not be the norm. Currently mm runs with a really barebones window manager (a WM is needed in case you run a windowed app, so it looks right), but with nothign else going on. But Pleng just augmented that with some more stuff as his preferrred environment. If you want, you can run minimenu from xfce easily enough.. not as a pnd. Just open up terminal and run 'mmwrapper -fmmenu' and mmenu will pop right up.

DaveC -- no performance changes; if Pleng runs xfce's window manager and does multitasking, thats his business; it will not be default setup, which will remain as is; he just wants the option to set a flag so that minimenu doesn't exit when an app is run, which is a trivial code change. (You can sort of see it now .. if you run mm, and run the Terminal from the menu, it'll pop up the terminal without exiting minimenu, and mm goes to a window until theres only 1 app left. But every other operation, mm exits and the app comes up full screen. Pleng just wants the option available, but we are certainly not making that the default. Default is still to keep thigns fast and light.) Even if I add plugin support, that'll be an option people have to turn on, so that peopel don't lose a second waiting for plugins to load if they don't want them, etc. Don't worry, I want to keep thigns fast too, and I already knew when I made my post that you'd worry about it The actual changes are in line with what you think though, right? (I'm mostly wondering if you agree with the approach for tabs by directory strucutre as detailed above.)

jeff

 

[Pleng]

Ohh another option on the pop-up menu which would be really nice would be 'Rename' so we can rename our emulators to the name of the console they are emulating. Makes it much easier when passing round to mates.

 

[skeezix]

Re: plugins

I have to write out my notes for plugin support .. I Was fiddling with it for awhile; in the end I figured the easier approach for step-one woudl be to support a limited couple kinds of plugins -- a 'new tab(s)' kind (ie: a weather or file browser tab(s)), and an 'event listener' that could post artwork/audio (so you could make a plugin to click when buttons pressed, or to show icons on the screen, or something); a plugin to replace the whole render engine, and plugins to handle new file types, woudl be too much for step one. (For file types at first I thoguht 'piece of cake', but you run into .. what if 3 plugins all report the same file, then you have to keep track of the one file and offer 3 ways to execute it potentially, and other complications. Can't be bothered to mull that over day one.)

As to how the plugins would work .. theres a few conventional ways to do it; the old school way was just to use shared libs in certain places, and load them up, with a standard UI; this way life is much easier -- just call plugin functions and pass them data from the main job. Easy .. but if the plugin crashes, it takes everything down with it, which sucks. Advantage .. easy as heck for everyone .. Disadvantage is security/stability. Other pros/cons -- a shared lib sort of implies 'same family' languages or bridging layers needed -- if you wanted to write a plugin in python, you'd have to write a .so plugin that in turn talks to a python session, sort of hackish.

So I figured to go with a stdin/stdout pipe style, similar to how a webserver runs a CGI; find the plugins, and invoke each as a process, with stdin/stdout hooked up between the plugins and minimenu; ie: for mm to send a message to a plugin, just send it to the stdin of the plugin, and vice versa. Plugins could then be written as sh-scripts or perl or python or C or whatever with no problem, just 'print' and good to go. Using say JSON as the 'protocol encoding' (but only very limited), so it'd just work for python, and be trivial for anything else. Then just a matter of what events and functions on both sides, and I prepared an incomplete list.. but plugins need a way to ask to be advised of key events, or tab change events, etc. (No need for timer events etc, since being standalone jobs they can run their own timers.) Likewise, plugin needs to be able to say 'hey, bring me to focus', or 'heres some config options' and 'render this and such'. Pros/cons here are that if a plugin dies, mm can just drop its tab or whatever and no blowups .. but its more annoying to code since no easy function calls per se.

I was worrying recently about sharing of assets; open up shared memory to pass over already loaded assets like background art, but that makes it a big ugly hack; occurred to me yesterday that I shoudl just define it in such a way that no asset sharing is needed -- let a plugin ask mm to pre-render the background and then call the plugin to trender its stuff transparently on top, say .. keep things nice and clean.

Anyway, we'll see if I tackle any of that; its a pretty big job, but pretty fun too.

jeff

 

[DaveC]

DaveC -- no performance changes; if Pleng runs xfce's window manager and does multitasking, thats his business; it will not be default setup, which will remain as is; he just wants the option to set a flag so that minimenu doesn't exit when an app is run, which is a trivial code change. (You can sort of see it now .. if you run mm, and run the Terminal from the menu, it'll pop up the terminal without exiting minimenu, and mm goes to a window until theres only 1 app left. But every other operation, mm exits and the app comes up full screen. Pleng just wants the option available, but we are certainly not making that the default. Default is still to keep thigns fast and light.) Even if I add plugin support, that'll be an option people have to turn on, so that peopel don't lose a second waiting for plugins to load if they don't want them, etc. Don't worry, I want to keep thigns fast too, and I already knew when I made my post that you'd worry about it The actual changes are in line with what you think though, right? (I'm mostly wondering if you agree with the approach for tabs by directory strucutre as detailed above.)

jeff

It would also be nice to keep the skinning as it is pretty easy now. If you go messing around there that means all new art, Ugh.

Yes the directory idea is fine but maybe designate a upper dir that all scannable PNDs are in (apps, or menu or something like that). Otherwise scanning all dirs on the card is too slow. I had mm taking like over a minute to scan so I had to re-organize things to speed up (it was scanning all of my ROMs folders and was slooooooooooooow).


Directory to tab thing:

An upper level dir called Emulators for example could be made. All PNDs put into the Emulators dir will appear under that tab. If someone wanted to have a sub-cat folder to appear in the icon grid (should be in grid not another tab, that doesn't make sense) they could make a directory under Emulators like Emulators/Computer, Emulators/Console. So in this example if you highlight the Emulators tab you would see a folder icon called Computer and a folder icon called Console. Note that if you just have a PND in the Emulators dir as well your panel will have that show as normal along with folder icons too. If you hit B on Computer the grid will now show all of the computer emus you put there. An indicator somewhere on the screen indicates you are in a subcat level, pressing a button such as A goes back up a level. That is fine but then the PNDs and any support files such as the icon, .ovr, pvw etc will all be in one big with pile and no way to group these in a subdir as it will think it is now a sub cat. I guess they can all be left "naked" together. This might be a bit unruly if you have lots of stuff but I guess it is not the worst thing.

I also agree that you could put the different menus in a pop-up thing instead of in that preview panel. There could be an option then to eliminate the permanent panel and have all icons if you want. If you hit that Y thing the panel could pop up and have the preview pic in there. This way you can read about the app and have a preview pic there. This eliminates the need to load preview as you hover over an icon. It only loads if you look at the apps info.

 

[Pleng]

An idea I had on the plugin side of things, and I have no idea how easy this would be to implement would be to use some kind of Webkit engine that has been modified to allow callbacks to bash commands. That way plugin interfaces could be written in HTML/Javascript with the back end being a (set of) command line apps.

So an example snippet could be something like this:

<div id='player controls'>
 <div class='button' id='play' onclick='mmExecute("mplayer filename --command_line --arguments");'>
   <!-- 'button' is defined in the master css, dictated by the minimenu theme --> 
 </div>
 <div class='button' id='stop' onclick='mmExecute("mplayer --whatever_the_commant --to_stop_is");'>
  <!-- 'button' is defined in the master css, dictated by the minimenu theme --> 
 </div>
</div>

 

[frefol]

That is fine but then the PNDs and any support files such as the icon, .ovr, pvw etc will all be in one big with pile and no way to group these in a subdir as it will think it is now a sub cat.

I don't know how hard it would be, but what if there was an option like "Folder Depth" where you would set how many subfolders to browse through.

Like if you had /pandora/menu/Emulators/Genesis and you set "Folder Depth" to 1 it would only create an Emulators tab and the Genesis folder would be for extra files or whatever. Or you could change "Folder Depth" to 2 and then there would be an Emulators tab and a Genesis subcategory. Then any extra files/folders in the Genesis folder would not show up so you could keep it clean. That's basically how my Unraid server does it and it works pretty well.

 

[skeezix]

DAveC -- this is wehy I mentioend the two options -- you can say you want one level of dir to be cat, and the second option to say that a second level of dir woudl be subcat; anythign beyond the one or two would be purely organization and ignored.

ie: If you're saying you only want the one level, then /pandora/menu/foo/emulation/wank.pnd would be in tab 'foo', with 'emulation' purely being organization; but if you then set the second level option on, it'd be subcat 'emulation' as well.

--

Pleng the idea of using webkit with some extensions is being deliberately avoided; minimenu is 'mini' to the point of starting up fast and working fast and to the point, without being crazy scriptable/flexible etc; also, it was written to be quick and do the job .. at the time, Craig was saying 'we're going to ship in a week, we need to get a simple menu going' and cpasjuste was away for awhile and pmenu wasn't suitable yet, so I werote mm in 5 days Its not _that_ extensible More to point, we always envisioned others taking that handle, such as when dflemstr was working on his webkit based super flexible fancy launcher thing .. theres xfce (lots of options) and mmenu (cut down and to the point); we see folks installing other desktopds (enlightenment etc) if they like, or writing up new fancy ones .. mm isn't going to grow into being big and fancy, its just not designed for it

(All that is to say I agree, since day one, that was something I've been thinking about, but its 'out of scope' for minimenu

jeff

 

[DaveC]

DAveC -- this is wehy I mentioend the two options -- you can say you want one level of dir to be cat, and the second option to say that a second level of dir woudl be subcat; anythign beyond the one or two would be purely organization and ignored.

ie: If you're saying you only want the one level, then /pandora/menu/foo/emulation/wank.pnd would be in tab 'foo', with 'emulation' purely being organization; but if you then set the second level option on, it'd be subcat 'emulation' as well.

jeff

Your first option is fine. I was just saying with that you couldn't have a folder in the upper level that is just organization in some less populated tabs and in other tabs where you want subhfolders (like games) have that too. It is all or nothing and global. My suggestion was to have some kind of extension or something to the folder to let MM know it is a subcat or something.

Also the subcats should show up as folder icons in the panel not as a tab as that is too much tab clutter. I didn't hear if you agreed with that or not.

 

[skeezix]

Not sure what to do with subcats .. ED wants the concept where you see main-tabs, and hit a button to pop up a list of subcats and switch to them; I sort of prefer the idea of showing a folder icon for them, so folks know they'r ethere.. but then the extra folder might just be clutter, so I can see both ways.

May have to add lots of options, not sure I did elude to it a bit .. if ytou have modal subcats, and you'r eat one, what do you see? just one tab wth the tab name, and a message beside it to clue you in to the fact that you're in subcat-mode, or something.

jeff

 

[DaveC]

Not sure what to do with subcats .. ED wants the concept where you see main-tabs, and hit a button to pop up a list of subcats and switch to them; I sort of prefer the idea of showing a folder icon for them, so folks know they'r ethere.. but then the extra folder might just be clutter, so I can see both ways.

May have to add lots of options, not sure I did elude to it a bit .. if ytou have modal subcats, and you'r eat one, what do you see? just one tab wth the tab name, and a message beside it to clue you in to the fact that you're in subcat-mode, or something.

jeff

EDs idea sounds awful. I am not sure why you seem to want to do that one the most. Why do that? Too "buttony" and awkward, plus you have to hit a button to even see them. Then you have indicators or whatever to know? What if you have like 10 or so subcats? With EDs idea are you going to have 10 sub tabs then pop up then have to scroll through those? That makes no sense and just sounds weird and confusing. I don't see what is wrong with having a folder in the bottom panel. Why is that "cluttered"? Having game icons there isn't cluttered why would a folder? By the way regular PNDs and folders can be mixed in the same panel, folders would just sort to be first or something. All computers work like that and it is intuitive and is actually LESS cluttered then tabs with indicators and messages with separate buttons for showing whatever :blink: With EDs thing you would have to read the instructions to figure that out, the other way is immediatly familiar and intuitive to anyone who has used a computer in the last few decades.

Tabs should just be for main catagories. If you want to further organize things then a subcatagory AKA a "folder" as in every computer these days, can be included. For example in a "Game" tab it just shows everything that is a game. Then if you want to organize by type then a folder there called "Racing", "Shooter" etc would appear with the other icons. Some you may not want to subcatagorize if it is unique but it is still a "game" and still should be under the Game tab. I do think the folders should sort to be first in the grid but other than that is logical.

 

[Pleng]

EDs idea sounds awful.

Well this is a first. Me and Dave C both agreeing on an concept for minimenu ...

Tabs should just be for main catagories. If you want to further organize things then a subcatagory AKA a "folder" as in every computer these days, can be included. For example in a "Game" tab it just shows everything that is a game. Then if you want to organize by type then a folder there called "Racing", "Shooter" etc would appear with the other icons. Some you may not want to subcatagorize if it is unique but it is still a "game" and still should be under the Game tab. I do think the folders should sort to be first in the grid but other than that is logical.

...Ah well... it was never going to last for long I suppose

Personally I think the folder analogy is a poor one. It's great for hierarchical data but this isn't a hirarchy; it's a filter. I would be much happier with a side view of sub categories to filter down the data, as showing in the second picture in this mockup (ok so this mockup doesn't have the tabs across the top so you'll need to use your imagination a bit). Yes, it only limits you to a depth level of one sub-category, but doesn't the PND spec already enforce that?

 

[DaveC]

EDs idea sounds awful.

Well this is a first. Me and Dave C both agreeing on an concept for minimenu ...

Tabs should just be for main catagories. If you want to further organize things then a subcatagory AKA a "folder" as in every computer these days, can be included. For example in a "Game" tab it just shows everything that is a game. Then if you want to organize by type then a folder there called "Racing", "Shooter" etc would appear with the other icons. Some you may not want to subcatagorize if it is unique but it is still a "game" and still should be under the Game tab. I do think the folders should sort to be first in the grid but other than that is logical.

...Ah well... it was never going to last for long I suppose

Personally I think the folder analogy is a poor one. It's great for hierarchical data but this isn't a hirarchy; it's a filter. I would be much happier with a side view of sub categories to filter down the data, as showing in the second picture in this mockup (ok so this mockup doesn't have the tabs across the top so you'll need to use your imagination a bit). Yes, it only limits you to a depth level of one sub-category, but doesn't the PND spec already enforce that?

A side view is a poor one too. One thing is it makes the screen too cluttered. Then how do you navigate that? You have shoulder buttons now switching tabs and pad navigating the grid for apps. That is simple. Navigating rows and columns of tabs will be awkward. Plus then you are limited to the amount of sub categories you can have as vertical height isn't much. The navigating is sequential and you lose the fast grid selection capability. It also wastes screen area. I know you tend to like sequential list type things where you go one by one to select for some reason and you must not like having many apps on your system. The method you mention is not very practical and offers no advantages, only disadvantages to the folder in grid method. Who cares if it isn't a "real" hierarchy ? It doesn't have to be to work well.

The folder method also has a "real life" advantage other than it being simpler, faster, more intuitive and that is it is much easier to implement. With this method it takes a bit of coding to show folders in the icon grid but that is about it everything else can be left alone. The other way the whole thing would have to be redone, the whole interface and art etc would all need to be totally redesigned. Considering Skeezix's mantra of "no time" , "Real life", "Too many projects" This has a better chance of being a reality.