Rockbox Technical Forums

Rockbox Development => Feature Ideas => Topic started by: seani on November 09, 2009, 07:25:14 AM

Title: *Not* another "Can We Have Custom Menus" Question
Post by: seani on November 09, 2009, 07:25:14 AM
Well not quite.


I've read through the proposals for menu restructure and understand the issues surrounding supportability if ad-hoc user defined menus were allowed. To summarise (I think)


So I'd like to get a feel for two suggestions:


Forget about explicitly repositioning / restructuring menus, but allow a menu entry to be suppressed.

In this case, link a string token in the menu definition to a setting in a .cfg file of some sort.

If the setting is "N" or "false" or whatever, do not render that menu item at the current level.

Some menu items are fixed and cannot be suppressed (TBD).

This behaviour only applies to "real" menus, not menus which exist to provide lists of values such as backlight timeout, i.e. you cannot limit the choices in a list to your favourites in this way,


If traversing a sub-menu ends in a single entry, render the entry in it's place

As an example, on my F40, my top level menu and an expanded portion of it's submenu reads:


  Files
  Database
  Resume Playback
  Settings
  Playlists
  Plugins
  System
    Time & Date
      Set Time/Date
      Sleep Timer
      Time Format
    Rockbox Info
    Credits
    Running Time
    Debug (Keep Out!)



With the top level reading simply:


  Files
  Database
  Resume Playback
  Settings
  Playlists
  Plugins
  System



In my .cfg file, I decide to suppress all but "Set Time/Date" on the "Time & Date" submenu, and I'm not interested in debug information or credits (how's that for gratitude?) so my expanded view is now this:


  Files
  Database
  Resume Playback
  Settings
  Playlists
  Plugins
  System
    Time & Date
      Set Time/Date



And because I suppress submenus with single entries and promote the single entry to the slot previously occupied by it's parent menu, I now get:


  Files
  Database
  Resume Playback
  Settings
  Playlists
  Plugins
  Set Time/Date


as my "new" top level menu.


There may have to be one top (or near top) menu entry "Menu Mode" as "Custom / Standard" to toggle between showing or displaying possibly suppressed entries.


I think this means that:

I never have *more* menus at a given current level than are already defined in the existing menu structure. I'm always - at worst - replacing a submenu entry with a commonly used entry that would otherwise appear further down in the hierarchy.

I can "remove" entries I perceive as complex / of little use and I simplify the number of options to navigate depth-wise, and possibly breadth-wise.

There is still an additional support burden, but that's mitigated by reference to the "Menu Mode" setting. There may also be legs in suppressing uncommon features by default so that "easy" settings require less intervention to find and explain.

In addition, the always present "Menu Mode" option could instead toggle between presupplied config files - "Simple", "Standard", "Expert" - adding a "Custom" to that list if the user defines one.


I think it would provide a relatively supportable way to simplify menus - "Custom" for values you change regularly, but flipping in and out of "Expert" to set other little-changed defaults - but I'd appreciate some opinions before pressing it any further,
Title: Re: *Not* another "Can We Have Custom Menus" Question
Post by: saratoga on November 09, 2009, 11:18:53 AM
I like this idea actually. 

Title: Re: *Not* another "Can We Have Custom Menus" Question
Post by: seani on November 09, 2009, 02:33:37 PM
I think that leaving the hierarchy in place but suppressing entries should mitigate some of the support issues.

If you're trying to direct someone to a setting, and that setting isn't suppressed, the user will always come across it by following the same directions as you'd give for the standard menu.

If the entry has migrated up the hierarchy they'll just come across it sooner than they expect, and if it hasn't, there may be fewer options to scroll through.

If it isn't immediately apparent, flipping to "Standard" from the top level restores it to a known state.

Some of the menu options do seem to have a lot of options that although undoubtedly vital to a subset of people will be irrelevant noise to another set.

The playback settings menu is a good example:


Settings
  Playback
    Shuffle
    Repeat
    Play Selected First
    Fast-Forward/Rewind
    Anti-skip Buffer
    Fade on Stop/Pause
    Party Mode
    Crossfade
    Replaygain
    Track Skip Beep
    Auto Change Directory
    Last.fm Log
    Cuesheet Support
    Pause on Headphone Unplug
    Skip Length
    Prevent Track Skipping


Comprehensive, certainly, but a bit overwhelming for the casual user?. I would think the majority of those are set-and-forget-forever for a lot of users, perfect for "Simple" / "Standard" / "Advanced" categorisation.

Personally I probably wouldn't have it appear at all by default.


I struggled a bit to understand the menu rendering logic, but I'll have another play :-)
Title: Re: *Not* another "Can We Have Custom Menus" Question
Post by: JdGordon on November 09, 2009, 10:33:13 PM
  • There are as many proposed designs for a restructure as there are people using their players regularly
  • Allowing total customisation would mean it's far more difficult to guide users to the correct settings to address related issues
  • Allowing total customisation looks like it would be non-trivial to implement from a technical point of view
  • There are issues concerning how a user would define "their" menu structure - PC utility? config file? - although with rose-tinted-precognitive spectacles, you could imagine a situation similar to sharing WPS files where structures tailored towards common use cases are shared.
point 1 is correct... 2 is a cop out answer... new users will get the default layout, support can always say "revert any menu changes or we wont help you". 3 is outright wrong... every menu item in the current menus is uniquely identified already (by its english language string), or for the case of settings, its cfg setting name. To build a menu tree is trivial (well, easy if you know what you are doing... 4) building a parser for the text file would be harder than building the tree from the menus... but we already have at least 4 (maybe more) text parsers in the core.. so one more wont hurt (tagnavi.config, viewers.config, skins, .cfg files are the ones i immediately think of).

Now, that said, what (I think) you are proposing is harder to implement because while you can dynamically hide menu items right now, you cant decide at runtime which to check for, you have to do it at compile time, which means you enable the check for everything, which means bloating the core with settings, and slowing down the menus because *every* redraw every item needs to be checked.


So, in my not so humble opinion, the only way worth the effort is to allow full menu customisation and bugger support.
Title: Re: *Not* another "Can We Have Custom Menus" Question
Post by: seani on November 10, 2009, 11:11:11 AM
  • There are as many proposed designs for a restructure as there are people using their players regularly
  • Allowing total customisation would mean it's far more difficult to guide users to the correct settings to address related issues
  • Allowing total customisation looks like it would be non-trivial to implement from a technical point of view
  • There are issues concerning how a user would define "their" menu structure - PC utility? config file? - although with rose-tinted-precognitive spectacles, you could imagine a situation similar to sharing WPS files where structures tailored towards common use cases are shared.
point 1 is correct... 2 is a cop out answer... new users will get the default layout, support can always say "revert any menu changes or we wont help you". 3 is outright wrong... every menu item in the current menus is uniquely identified already (by its english language string), or for the case of settings, its cfg setting name. To build a menu tree is trivial (well, easy if you know what you are doing... 4) building a parser for the text file would be harder than building the tree from the menus... but we already have at least 4 (maybe more) text parsers in the core.. so one more wont hurt (tagnavi.config, viewers.config, skins, .cfg files are the ones i immediately think of).

Now, that said, what (I think) you are proposing is harder to implement because while you can dynamically hide menu items right now, you cant decide at runtime which to check for, you have to do it at compile time, which means you enable the check for everything, which means bloating the core with settings, and slowing down the menus because *every* redraw every item needs to be checked.


So, in my not so humble opinion, the only way worth the effort is to allow full menu customisation and bugger support.


I should say that's my understanding looking at the code as of a few nights ago. Having read the Developers Docs for the Menu API and messed around with it a bit, I think I have a better picture of how it hangs together.

And the bullet points are mostly my interpretation / precis of the points already discussed in various places. I defer to your opinion that you can bugger support :-)


I'm not sure you have to bloat the core with settings, though? The approach I've been looking at is that when the submenu list is scanned to build up a list of candidates for display, I check the menu text for a candidate entry for it's presence in an array of strings. If the string is present, I don't add the entry to the candidate list, so it never gets rendered.

At the moment, I'm just intending to use the display text itself - "Playback" or "Last.fm log" - and if I find a match, I don't add it to the candidate list for rendering. I might combine with the parent text "Settings->Playback" to minimise the risk of clashes. That doesn't do the "peek ahead to see if there's a single submenu option" stuff, but one bit of playing around at a time.

So that means I have a very simple config file that contains a list of strings that I match against and if I find a match I suppress. I don't think it means multiple / exhaustive settings flags in terms of bloat.

As it stands it certainly means more processing when the menu is rendered, but I don't think it makes it "harder". In theory anyway, I haven't got much of anything going yet, but it's illuminating to try.