Reorder menu items

[fml2]

Hello.

I've made a patch (http://www.rockbox.org/tracker/task/7809) for reordering items in RB menus. It's done as follows: each menu item in RB gets a unique name (the names are assigned automatically, you can't change them). You then create a text file with the extension '.mnu' and assign each item a priority. Then you 'play' that file. After that, items with higher priorities will go to the top of their respective menu. Default priority is zero.

It is not possible to pull an item from one menu to some other menu. Also, it's not possible to hide a menu item. Only reordering is possible. And only in core RB menus. Plugin menus are not affected.

Here is an example of a .mnu file for reordering the items in the main menu for H120 in this order: Files, FM Radio, Resume Playback, Settings, Database, Recording, Playlists, Plugins, System

# full coverage: no
file_browser: 100
fm: 90
wps_item: 80
menu_: 70

Here, the four items (Files, FM Radio, Resume Playback, and Settings) have been assigned priorities other than default. Other items retain their positions.

As a side effect, automatic menu reordering is possible: you start with the default RB menus, use your DAP, and then the items you use more frequently automatically go to the top. Automatic reordering can be switched off (and is off by default).

Some developers were rather negative about this feature (no do, evil, etc.). There was also positive feedback. As of now, my estimation of the chances for this feature to be included into RB is about 0%. But if we discuss it here and many like it, the developers could change their mind.

[Mikerman]

I think this is a nice idea.  I've always wanted to move bookmarks down from the top of the menu listing, thinking that the broader files category should be on top.

I especially like the automatic sorting facility--that sounds like a great solution.

I do wonder if the system is a bit more complicated than necessary--couldn't one simply list, in order, the listing that one wants without the assigning of priority numbers?  Just a thought.  Although, of course, this is not a big matter.

Thanks!

[fml2]

I think this is a nice idea.  I've always wanted to move bookmarks down from the top of the menu listing, thinking that the broader files category should be on top.

I especially like the automatic sorting facility--that sounds like a great solution.

Nice to hear! As to the automatic reordering, I thought of it as a way to set up the order without having to explicitly learn your own habits. Just use the dap for some time, and then dump the menu config -- and you'll have menus that fit you. After that, you can disable automatic reordering.

I do wonder if the system is a bit more complicated than necessary--couldn't one simply list, in order, the listing that one wants without the assigning of priority numbers?  Just a thought.  Although, of course, this is not a big matter.

The idea was that you can list the items in whatever order you want. But it would also be possible to write another plugin that would respect the order of the entries in the file. The underlying data structures etc. in RB would be the same.

Now we have to make noise so that this topic gets devs' attention! :-)

[AlexP]

I really don't think it'll happen no matter how much noise you make (especially for automatic reordering), but feel free to try.

[bluebrother]

Now we have to make noise so that this topic gets devs' attention! :-)

Reordering of the menus was discussed quite several times, even upon devs ...

[fml2]

Reordering of the menus was discussed quite several times, even upon devs ...

...and has always been rejected, right? But I still hope that not because of the principle itself but because there was no solution to this that would be elegant and simple and usable enough to be included into RB. (I don't state my solution is good enough. I also don't state the opposite. ;-) I mean, the main menu was a no-no once and then discussion started. and now we have it.

[bluebrother]

Reordering of the menus was discussed quite several times, even upon devs ...

...and has always been rejected, right? But I still hope that not because of the principle itself but because there was no solution to this that would be elegant and simple and usable enough to be included into RB.

I'm sorry, but unless I'm completely wrong on this it wasn't rejected because of no solution being present -- if that feature would be wanted there wouldn't be a reason to reject it (maybe the tasks would've been closed as "later" but not as "rejected" -- if a feature request is considered there is usually one task in the tracker about this left open).

In general, customizable menus (1) cause increase of the binary size (which is always a matter) without a real benefit, at least from the viewpoint of most of the devs, (2) create a *major* headache for support (which is a *huge* issue, especially since the Ipods came in and the demand for support increased immensly) and (3) creating additional issues with voice. In other words, it opens a can of worms. And we have enough worms around already

[fml2]

In general, customizable menus (1) cause increase of the binary size

Agreed. But every feature does it.

(2) create a *major* headache for support (which is a *huge* issue, especially since the Ipods came in and the demand for support increased immensly)

How would it be a major headache if the items wouldn't dissappear?

(3) creating additional issues with voice.

What issues do you specifically mean? If all the items are still correctly voiced after reordering, I don't see a problem here.

[Llorean]

Just because every feature causes a binary size increase, doesn't mean that every feature is equally worth binary size increase.

Many people argue "But it's only X bytes" as if less increase makes it better, but really ANY increase can be considered bad, simply because they add up over time.

Another concern of course is code complexity, parts of Rockbox are hard enough to maintain as it is.


As for difficulties with voice, I think he meant with blind users in general. Should the option accidentally become disabled, they're going to get similar symptom to having a bad voice file (that entries are no longer read in the same order) despite the fact that everything is working properly.

This really just has the potential to create a vastly increased support load.

Why not work on reorganizing the existing menu structure to be more usable? One of the bigger problems is likely the categorization rather than the order within the category anyway, most options are used so rarely that it's finding them that's difficult, rather than one or two extra button presses to get to them down the list.

[fml2]

Why not work on reorganizing the existing menu structure to be more usable?

Actually my main concern about the menus is the order of the items in the main menu. And just a couple of entries in other menus. Other menus aren't used that often (by me). That's why I once made a patch for reordering of items just in the main menu. It was admittedly ugly, even I didn't quite like it but it worked. Then I had an idea how it can be made (IMHO) in a more elegant and general way, and so that every menu can (but does not have to) be reordered. If, at some time, the developers (or the rockbox community) will decide to reorganize menus (group them differently), this solution still will work since it is orthogonal to the menu structure.

[fml2]

So am I right that nobody is interested in it?

[cc]

You mean nobody, or 'nobody important'?  

I was quite interested in seeing what you had done and how you had done it. I'm not sure how useful it would be for me - I have a sansa e280 with a wheel thing, so all the entries are pretty much the same effort to get to - except the first (super easy) and last (pretty easy). The only menu I'd think about rearranging is the root menu, but there are more than 2 things on there I use regularly, so there's no point for me really.

[fml2]

You mean nobody, or 'nobody important'?  

I mean nobody. 'Nobody important' would be half as bad :-/

[shoe]

I'm interested.  I reorder my menus manually whenever I update RockBox (meaning I edit the code and recomplile), the order of entries in the WPS context menu is especially important to me.  I dont care much for the automatic reordering but to be able to reorder manually (without recompiling) would be great.

[Mikerman]

Shoe, which are the files to edit, for future reference?  Thanks--