RB - simple mode

[oayz]

Of cause we all enjoy tremendous amount of features in RockBox. Some of us is trying hard to convience our dear developers to put more and more :-). However for some people this is overkill and can actually turn them away from RB.

Suggestion - implement "simple" and "advanced" modes of oparation. In former one only most important features are available. I guess the major job is to re-organize options menu.

[saratoga]

This is actually on the NoDo list linked at the top of this forum. 

[oayz]

That's right, sorry. Just wanted to give my player to kid but he is confused with all these features.

So we should wait for configurable menu.

[gevaerts]

So we should wait for configurable menu.

You can do that, but the most effective thing to do would be to work on configurable menus

[oayz]

If it's not prohibitive from RAM footprint point of view ....

Can we have a text file which looks something like this:

MunuItemLevel1
-MunuItemLevel2,@function_ptr
-MunuItemLevel2,@function_ptr
MunuItemLevel1
-MunuItemLevel2
--MunuItemLevel3,@function_ptr
-MunuItemLevel2,@function_ptr

Notes:

There is always a full ("advanced") list. Users can edit,delete or re-arrange menu entries but not add new ones.

"MenuItem" is text displayed in the menu
"-","--","---" etc defines menu level (1,2,3 etc)
function_ptr is a name(or address or any other ID) pointing to the code which actually displays adjustement screen (on/off, value list etc.)

The parser reads this list (statically or on the fly), displays items of currently selected MenuLevel and on select calls appropriated function.

Probably need another ID for icons ... is anything else missing?

[evilnick]

(I think that) the issue here is that if the menu is "set" at compile time then there's no overhead in terms of memory, which you *would* have if the menu had to be parsed each time/boot.

Even if my assumption is incorrect, giving support to people who have messed up their menu wouldn't be fun - we'd be adding a new vector for a lot of people to accidentally render their build unusable and besides which, there's already a way to have less menu items:

If you're after less menu entries then the best way would be to "roll your own" build and remove (comment out?) the entries that you don't want.

That way, you'd have a build that would work for your kid without affecting all the other users. (Although that means that you'd have to build it again each time there's a change that you'd want on your kid's player).

[AlexP]

Customisable menus are no longer a nodo - we decided at the last devcon that if someone could come up with a good method of implementing them, then they are allowable.

[saratoga]

I wouldn't mind having multiple different GUIs available in rockbox.  Right now we're completely tied to our current system, but in the long run that should probably change.  For instance, I could see a more graphical or icon based system being better on Android or touchscreen player, while the list interface works better on players with buttons and wheels.

[Avalon]

I personally like having all of the options available.  Perhaps it would be useful to have a setup function to toggle between displaying 'all' available menus and a configurable subset.

That way, none of the configuration flexibility is lost and if desired, a very simple menu could be used for normal use.

Is it possible to set up a cross reference table listing all menu items with a selection toggle by each?  A single menu selection can then toggle between all menu options and those selected in the table.  The table could be edited on the fuze or via pc.

I use my Fuze V1 (8gb+16gb) for mp3 playback.  The only settings I change are set up on the quikmenu in a custom wps.  I can see where it would be useful to set up the Fuze (after configuration) to only toggle between pictureflow and the wps for a child to use.