Rockbox

I feel that Recent Bookmarks and Browse Plugins should be removed from the Settings Menu with this patch. It would also be nice if the submenus also had a title (e.g. “ROCKbox - Browse File System”.) I’ll see if I can alter the patch to do these things.

I played with the patch on the h120 sim. Will do on target later.
- IMO the setting for the root screen should be in the “Display” menu entry, not “System” - I set startup screen to File Browser. I _really_ dislike the fact that it goes from the file system root back to the new root screen by pressing left even if I set the root screen to be the file browser. I would expect to go to that screen by pressing left _only_ if the root screen is actually set as root (startup) screen and use the button that toggled the main menu before for accessing the root menu. (the same happens if other screens are set as root screen)
- the mode button goes to the settings menu from the file browser but not when the root screen is active. IMO the button that toggled the main menu before (mode in my case) should toggle the root screen (as that screen is the new “main” menu and allows accessing the settings which had been done with the main menu before)

Basically, I think this should be a rework of the old main menu, allowing to set different screens as root (as it already does) but understand the root menu the way the old main menu (which won’t be needed anymore). That way someone could easily achieve the same behaviour as before by simply setting the file browser as startup root menu.

dan_a: forgot to remove those 2 options… as for titles for the submenus, thee is an option to have a title in the file browser already whic doing this would conflict, So dont think we should do this.

bluebrother: Are you suggesting that in the browsers, you ave to go through the root menu to get to the main menu if they are set to root? I dont think thats good… I can make it ignore the first press to quit when your in / and the 2nd would exit, but even tats not very nice.

JdGordon or someone else care to explain/summarize this patch for people who weren’t present for the “irc discussion”?

it adds a new menu with items for the file/db browser, wps/fm/rec screens and a few other options which is the first screen rockbox loades into unless changed in the setting.
just to annoy the left-too-wps people :D
http://www.rockbox.org/twiki/bin/view/Main/RootMenu

I still think that Browse Plugins should be Plugin Browser because theres File Browser and Database Browser - just soudns more consistent

1. I would like to see (although I don’t know if it’s possible) the ability to re-order the main menu items from within Rockbox. I don’t really use the file browser, but I use the Database Browser all the time, so I’d like that at the top and the File Browser closer to the bottom.

2. I think that Main Menu should be renamed (settings would probably be a good name).

3. I agree that it should be Plugin Browser to be consistent. If nothing is playing and you try to go to the now playing screen, it should act much like the play button. Resume if it can, if not say “Nothing to resume” or “Nothing is playing”

4. I think what bluebrother is saying is that if he sets the startup screen to file browser, he doesn’t want to see the root menu at all. He’s saying it should act more like another display type (ex. Files, Supported, Database) and less like.. an actual menu…? I kind of disagree with him because I think that this helps to navigate Rockbox. Maybe another setting to disable the root menu should be added?

Chris: the are that because i was too lazy to create new lang items for them… they will be fixed..

tihs version voices the items, and displays the background correclty coming out of the wps. also removes bmarks and plugins from the settings menu.

   root_menu.patch (23.6 KiB)

patch fails probably needs a resync :)

==
Naru rockbox # cat root_menu.patch | patch -p0
patching file apps/main_menu.c
Hunk #1 FAILED at 281.
Hunk #2 succeeded at 375 (offset -10 lines).
Hunk #3 succeeded at 387 (offset -10 lines).
1 out of 3 hunks FAILED – saving rejects to file apps/main_menu.c.rej
patching file apps/recorder/radio.c
Hunk #2 succeeded at 366 (offset 8 lines).
Hunk #3 succeeded at 584 (offset 8 lines).
Hunk #4 succeeded at 598 (offset 8 lines).
patching file apps/recorder/radio.h
patching file apps/tree.c
patching file apps/lang/english.lang
patching file apps/tree.h
patching file apps/settings.h
Hunk #1 FAILED at 268.
Hunk #2 succeeded at 676 (offset -3 lines).
1 out of 2 hunks FAILED – saving rejects to file apps/settings.h.rej
patching file apps/settings_menu.c
patching file apps/settings_list.c
Hunk #1 succeeded at 778 (offset 79 lines).
patching file apps/tagcache.c
patching file apps/tagcache.h
patching file apps/SOURCES
Hunk #1 succeeded at 26 (offset 8 lines).
patching file apps/root_menu.c
patching file apps/root_menu.h
==

ok, brand spanking new version :p
This one uses the new menu system and hopefully will be very easy to play with the options if we decide to… some highlights..
the now playing item changes its name to resume playback if nothing is playing :)
the GO_TO_ defines order means nothing (as long as _PREVIOUS and _ROOT stay where they are..) before the determined the order in the menu which made things messy… the bookmarks item will hide itself if your not using the recent bookmarks setting (Im hopeing this will be allowed.)

   root_menu.patch (31.6 KiB)

Ok, patched root_menu,
This one seems to be working fine :)

The problem i had that it was impossible to browse filesystem or database is solved in this new patch.
It’s working fine, and i like it.

Jonathan you Rock(box) :)

Correction, now I can see browse filesystem and database but still it won’t work
strange…..
when playing and i go to root menu:
browse filesystem –> go’s to wps
database –> Database not ready

I reinitialized database
and now database –> go’s to wps either

But still, i like the rest of root menu :)

Unfortunately there are a couple of issues.
- the “Settings” menu repeats “Browse Plugins” - The “Start Screen” setting is hard to find below the “System” settings. As that also controls the resume setting it should be better put somewhere else IMO.
- The “Resume on Startup” setting (in General Settings / Playback) is still present. Should be removed (as the startup screen option now does this), currently it doesn’t work.

Much more problematic issues are:
- pressing “Play” from the startup screen doesn’t resume playback but enters the selection. “Play” from the file browser resumes playback as before but it should work from the startup screen too. I’d also expect “Play” to go back to the wps when playback is running – we have an entry, why don’t we have a working button?
- when there is a dynamic playlist changing to database / file browser view is broken: it just resumes playback (but this doesn’t seem to trigger every time, looks like it sometimes gets into this state and only rebooting helps). This makes roloing impossible and testing a real pain :(
- stopping playback always drops you back to the startup screen, even if your last view was the file browser or you set the startup screen to file browser so this looses the last position in the file browser. I’d expect stopping playback to give you the last position in the browser rather than the startup screen. (not necessarily in for the settings browser but it should work at least for database and file tree view)

William, ok ta, ill look into them. same for Dominiks first 3 points..

pressing play - yes it feels wierd for me also, but we have a little problem.. do we want play to goto the wps from inside every menu? I think yes but if not this could get icky :p
when there is a dynamic playlist changing to database / file browser view is broken: - ? like when it moves automatically to the next folder?

and re the last point… you have the idea of the root menu wrong… its not the screen that will always be dropped back into.. its the opening screen for rockbox.
Because of the 2 tree browsers, what I am thinking of doing is adding an option to set the default one (tree or db) which select in the wps would take you to (and _possibly_ would drop you in after stopping playback), but more importantly would be the option at the top of the list (and the other one would be further down, probably 2nd :p )

Jonathan,

I just described how it worked on my device (h120), not how I want it to be - I think we want “play” to go the the wps from all screens. This has been discussed in some FS task as well, and IMO it’s much more consistent if all screens do that (as long as we have a button for “play” on the device of course).
- I have automatic folder changing disabled. Sometimes (but not in all cases) the root menu doesn’t change to database / tree view anymore but instead switches to wps. I wasn’t able reproducing this every time, but I was able reproducing it a couple of times. So I’m pretty sure there is something wrong: start playback, then stop it. Check if you can switch to tree view. You need to do this a couple of times until it triggers. It isn’t reproducable every time, but when it comes in I haven’t found a way switching to the file tree anymore. Sounds like some nasty runaway pointer thing to me - currently the root menu is the screen I’m getting always dropped to when stopping playback. That’s not the way I think it should work (and if I understood your comment correctly it also isn’t the intended way). Apart from that, I’m not sure if resorting the menu is a good idea (especially when thinking of blind users), but at least it sounds interesting.

My understanding of the root menu seems to be different to the last few comments - I thought it _would_ be the “root screen” in Rockbox. i.e. a normal exit from any of the screens would take you to the root menu. Stopping playback in the WPS exits the WPS, so you should be dropped back to the root menu.

I’m not sure I understand how else a root menu could work…

I agree a root menu could work this way. But I want to be able getting the same behaviour as before.

To achieve this, the root menu should be user selectable in terms of which screen is the root screen: the root menu, the file browser, database view etc. That way someone (like me) could set the file browser as root screen, and stopping playback will drop back to the file browser while stopping playback for someone who set the root menu as root screen would drop back to the root menu. In the same manner the file browser could leave (by pressing “left”) to the root menu _if_ that is set as root screen, but IMO it should _always_ stay in the file browser if _that_ is set as root screen. The root menu itself should always be accessible like the main menu was before (as it mainly replaces that menu).

That means the setting wouldn’t be “startup screen” but rather “root screen”, and Rockbox would always start from the root screen. If the “root screen” is set to something else than the root menu all other screens could be accessed through the root menu, which is always accessible through the “menu” button. The root menu could also be made leaving to the selected root screen by pressing “left” (but it could also made a toggled menu with the menu button).

I hope I made this clear … I find it a bit confusing with all that “root” stuff (maybe we should call the current “root menu” simply “rockbox menu” and speak of “root screen” which is the root of all screens in the menu hierarchy and “rockbox menu” which is simply a screen in that screen hierarchy

this doesnt work.. what if you set the root screen to be the wps?

I don’t see a problem here – you can simply disallow the wps to be the root screen and use the “resume playback” option that already exists. That option could even be extended to select between “resume playback” and “resume radio playback” for devices with a tuner.

How would you otherwise add the ability to get the same behaviour we currently have?

Can’t we just have a root screen which is a screen that appears when the DAP is switched on, then keep the current behaviour of being able to go back from the WPS to the File/Database browser?

well.. the plan was to remove the resume setting and use the start screen setting for that (so radio, rec, trees or wps would resume, (also there is the previous option which puts you in the screen you turned the dap off in).. ).

Now, fortunatly, the code is done in such a way that we can be very flexible with this screen.. So with that said I am offering a compromise… Pressing menu in any screen will ALWAYS take you to the root menu (from now on “Rockbox menu”)
pressing play in any screen will put you in the wps.
now the fun part….
I’m willing to add a setting to choose where to put you if you exit a screen normally (e.g OFF in the trees), Left will not exit a screen
Also, (i tinhk i mentioned this), I’m thinking about a setting for the tree/db priority, so the set one would be at the top of the menu, and it would be the screen you are put in when select is pressed in the wps.

Would these make everyone happy?

*Smiles from ear to ear*… *pulls off top of head*: I wonder if there would be slightest possibility of customising the names of the menu titles in the root menu (to please everyone)

Nope… unless you want to create a lang file especially for that :p
edit: i mean, useing a custom lang file with the only changes being those strings….

I agree that as far as possible we should try and maintain the existing Rockbox behaviour, but IMO the UI could get more confusing if we try and mix the old concept of “file browser is root” with the new concept of “Rockbox Menu is root”.

All I mean is that the priority should be making “Rockbox Menu is root” work nicely and consistently, and not make compromises in order to keep the current behaviour.

In my mind this means assigning a consistent button (MENU?) which will exit any screen and take you back to the Rockbox Menu. Other buttons can be used as shortcuts between screens, and I agree those could possibly be configurable (e.g. which browser NAVI/Select takes you to), but I don’t think we should configure what happens when you exit a screen - that’s too fundamental to navigation.

I totally agree with Dave.

Personally, I think the screen organization should be simple and easy to grasp for the user, which I thought was one of the goals of this exercise. If we start to add a bunch of settings to get back the previous behaviour, what have we gained?

I’m getting a little fed up with the fact that we aren’t able to change anything in the UI without having to add new settings to be able to retain the old behaviour.

We can’t please everyone, but I do believe we can come up with a better and simpler UI than we have today.

sorry bluebrother.. Linus have the veto vote…

Now, one other thing… Should the database view be taken out of the dirfilter option? Making it impossible to get into except through the rockbox menu?

Well, I don’t know of any veto, but I am definitely tired of the slow progress on the UI front.

Regarding the database, I don’t know if it should be considered a filter or a separate viewer. I’m not a database user myself, so I’ll leave that to those who have a better feeling for it.

I use the database myself, and I think that with this patch, the database should be removed from the view change in the file browser… It makes no sense to go to the file browser to view the database if there’s another option for it in the root menu. I go to browse files to view the files, not the database…

to please everyone, maybe there could be an option “always enter filebrowser in the directory it was last in & follow playback”. I think this could make bluebrother happy. In fact, this option is already there in the settings, it would just have to be extended to the root menu.

I would vote to remove the filter, because with the root menu the database is on the same level with filebrowser and there is an easy way to enter both through the menu. It would be nice to have a shortcut for switching in the context menu for filebrowser/database, though (or a button combo, e.g. PLAY + REC on irivers).

The SELECT button could enter the filebrowser if the last entered viewer in root menu was filebrowser and database if the last entered in root menu was database. This way users who don’t want to fiddle with settings can have a nice one-button usability, too.
And we (hopefully) get rid of the quickscreen/databese bug, too.

Actually that makes sence.. Ill keep track of the most recent browser (file or db) and if GO_TO_LASTBROWSER is returned it will go to that (most likely from the wps and recording screens so it should feel natural for the user)…

OK,
Well, I’m slowly getting fed up with that.. so lets aim to commit this maybe thursday?
The most impportant thing we need to agree on is the items to go in this menu, their order and their names…. he who yells loudest will probably win here… so hit the wiki :p

   root_menu.patch (39.4 KiB)

Small button config issue - on the H1x0 remote, play acts as select, not as play, so pressing it on startup takes you into the Recent Bookmarks menu item, and doesn’t resume.

Also, it feels odd to press right to get into e.g. the file browser, but left does not go back to the menu.

Jonathan,

I don’t think setting a hard time limit will help in any way as this patch changes the interface quite heavily. Anyway, just installed the latest patch and so far it’s coming along.

- “Stop” should stop playback from the Rockbox menu – it did so from the file browser / database and still does, so it’s strange it doesn’t work, especially as “Play” is a shortcut to resume / wps from the Rockbox menu.
- it seems “Left” jumps a bit too far back: go to database view and browse to some entry (make sure you have at least two levels used). Now open the menu, go to the file view, browse around. Go back to the database view and press left. For me it reproduceable jumps back to the root of the database view.
- The “Start Screen” settings duplicates some entries (but I guess you noticed that yourself already)
- The entry “start screen” for “start screen” is somewhat weird. IMO “Rockbox Menu” would be a better naming.
- maybe a second “left” press from the file browser root to go back to the menu is worth a try _if_ we keep considering this as a root menu. The way this patch currently works is more like the replaced-main-menu, but speaking for myself I like it better that way (as long as the shortcut keys still work the way they did before, which they do except for the stop button issue)

I’m on a journey tomorrow and will try to play around with it a bit. So far it looks way better than the older versions

Jonathan Gordon:
Last time i mentioned a bug about not beable to view files from database or filebrowser, Have you done some work on it yet?
I’ve used your new patch (posted on Tuesday, 13 February 2007), also this doesn’t solve my problem.

I’ve patched against a fresh svn gave me two warnings like last time.

And this is how i would like the Root menu aka rockbox menu:
Show Files
Show Database
Plugins
Recording Screen
System (Instead of Settings as there are some items in old main menu aka settings that are actualy not settings eg Info)
Now Playing / (Resume Playback when playback is stopped)

“play” Button should always go back to wps (except from plugins).
“Menu” Button should always go to rockbox menu (except from plugins).
“right” and “left” used for navigation (i mean you can select a menu item with scroll and press “right” and it goes to the selected item or press left to go to previous screen as it currently does, but this one should not be removed as it’s very usefull).
When you press “left” rockbox menu it should go back to wps.

But that is just my idea how i would do it :)

Keep up the good work!

Add it as another suggestion on the TWiki William :D

It was suggested that pressing PLAY sould always lead to WPS. But what if I’m listening to radio and call up the menu? In that case, PLAY should show the radio screen again. In other words: PLAY should lead to the current ‘sound producing’ screen. This can be WPS or radio (of course, only on the DAPs that have it).

should play always resume the previous “audio” screen? or only from the menu?
e.g if you leave the rec screen and go into the tree, pressing play will put you back in the rec screen?

(attached is synced patch )

   root_menu.patch (42.5 KiB)

Comment by Jonathan Gordon (jdgordon) - Wednesday, 14 February 2007, 10:30AM

I’m not sure about how it should behave with the recording screen since it’s not a ‘producing’ screen. But I think I like your idea. If I’ve called up the menu from the rec screen I want to be able to return there quickly as I’m mentally still in that context. If I want to switch the context (e.g. start mp3 playback) I’ll go to file browser/database and will explicitly select a song.

I think he meant specifically playback of Audio. Because Resume Playback from Recording wouldn’t make much sense xD

OK,
We are almost there….
the last things to do is fix the play button in the main menu keymaps for all targets (hxxx and x5 done, not remotes tho) and fix the bug with the file tree.. For some reason going file browser > wps > files doesnt let you out of the dir, and the database viewer always exits when you press left.
f someone figures them out they geta virtual cookie :D

   root_menu.patch (47.6 KiB)

Patch needs syncing… please…

resynced to svn.
We need the keymap file fixed for all targets before we can think about commiting… (iriver hxxx and x5 done)

   root_menu.patch (47.3 KiB)

and this one shouldnt give any warnings..
Fixes both bugs in the browsers…
fyi, You cannot resume your position in the db browser because of flaws there, not in the root menu patch. (hopefully this will be looked into at a later stage)

Im bassically happy with this as it is. Every target should have the jump-to-root working in the menus (pressing the usual menu button), and the major menu items are in the correct place… once its commited we can figure out exactly which other ones should go in the root, and which targets gets more shortcuts

   root_menu.patch (48 KiB)

I’ve added fixed keymaps for the H10 and Sansa. Otherwise the patch is unchanged from jdgordon’s latest version.

   root_menu.patch (50 KiB)

This patch includes Barry’s key changes, changed icons for the file/db/wps item (better?), sync to svn, and changed the way the wps item gets its name..
Also hopefully fixed all the browser bugs.. (again :P)

   root_menu.patch (49.9 KiB)

and this one fixes the last of the menus which linuxstb suggested go in the root.
I know this will jinx it.. but I think this one is good to go….

   root_menu.patch (64.6 KiB)

- the Database view doesn’t save it’s position anymore, even when returning from wps to database view
- the startup screen settings seems to be gone – I can’t find it in the menus anymore, and the lang string (LANG_START_SCREEN) doesn’t seem to be used anywhere.
- I still think “stop” should stop playback from the rockbox menu.
- the browser deadlock seems to be gone. Will try more later.

we had to remove database resumeing… it was never meant to be used like this.. So after commit it might be fixed… but its not critical imo..
missing setting, ok, ta
stop, we can argue that later :)

I think the database resume *is* critical. If it doesn’t work, the database users will complain, and it will give a bad first impression of the root menu.

Iriver H1x0 remote keymap is incorrect - play acts as Navi not play, i.e. pressing play selets on option rather than resuming playback.

You’re gonna hate me for this, but I’ve found a couple more issues:

1) Going from WPS→Broswer, then back up to /. Back up again brings me back to the WPS. I think it was agreed that it should bring me to the root menu.
2) Play a file from the file browser. Now go back to the root menu and click on Database. I don’t have a database, so it gives me the not initialized warning. Now go back to the WPS, then try WPS→Browser. It gives the database not initialized warning. So, basically it’s going back to whichever browser (file or tag) we last selected from the root menu. IMHO, it should instead go to whichever browser the current playing track was run from.

Linus: I can get the db resuming working again, but it wont make the nicest code, but I think I agree about making a good first impression, after all the code can be fixed later.
Alex: ta, itll be looked at
Barry: 1), damn I keep forgetting.. Ill fix that tomorow, 2) sort of ties in with the other DB problem.. I’ll look into it.

So I dont keep forgetting what needs to be done Ive edited the wiki… add to the list if you find more bugs, (or post here again)

Here is the latest version with all the bugs fixed (hopefully).

The last thing then is keymaps, and so I need ppl who has the targets to either tel me how it should work or (preferably :) ) fix the keymap file. (Barry, Ive added the ACTION_MENU_STOP action so playback can be stopped in the menus as was suggested, so let me know if you think the keympas you did need replacing)

   root_menu.patch (50 KiB)

Jonathan: your patch is outdated – it applies cleanly to r12394, which is 3 days old but not a current version :(

Still bugs:
- go to settings / general settings / language. Back out with “left”. Instead of going back to the general settings screen it stays in the file browser and displays .rockbox as folder title. Not sure if this is related to this patch, I don’t have an unpachted version at hand.
- the same for “browser fonts”, “browse wps”, and I guess all other submenus that use the browser; even for the “browse plugins” from the Rockbox menu.
- The setting for the startup screen is still missing.
- I’m still missing “stop” to stop playback from the Rockbox menu (at least on h100). It was considered a bug the time it did not work from the file browser, so if it’s not working from the Rockbox menu it will be considered a bug (and a lot of users will start whining)

Also:
- the “Show recording screen on startup” in the recording settings should be removed (in favour of the new startup screen option)
- the recording settings submenu should go directly to the settings and not have a “recording” entry anymore as that is now part of the Rockbox menu

serves me right for having the same filename in a few folders… I uploaded the wrong version :p
This is the correct one.. All of the above comment should be working.

   root_menuTHISONE.patch (77.5 KiB)

unfortunately not everything is solved:
- “Stop” from the Rockbox menu doesn’t respect the “fade on stop / pause” setting (works correctly from the file browser)
- The folder issue I mentioned (1st bug in my latest post) is still present

The other issues from my latest post seem to be resolved. Let’s see if I stumble across other issues (I hope not so

I cant reproduce the folder issue :(
stop in menu acts like ti should now.
usb problem fixed

   root_menuTHISONE.patch (77.9 KiB)

fixed the folder bug

   root_menuTHISONE.patch (78 KiB)

I’ve just tried this out with latest svn on my Gigabeat F40.

I tried the “Resume playback” option from the very first section of the menu, and got:

Data abort
at 0006ACF0

I had a very quick try of the latest patch with recent SVN and found some important things (sorry for the lengthy post):

As I understood the same buttons (or sequence on Ondio) that lead me from WPS to the main menu in SVN should bring up the root menu now. This doesn’t work correctly for me as this will only bring up the settings menu. On Ondio going to the main menu consist’s of two parts due to the lack of buttons: in the WPS “hold Mode” to call the WPS context menu (this works correctly still), and from there you have to “hold Mode” again (only gives me the settings menu at the moment).
Now that I think of… as far as I remember this way was introduced to have a “shortcut” to the main menu - i.e. when entering it from WPS you could easily back out to the WPS again with leaving the menu. Of course you can enter it via the filebrowser (meaning - going from WPS to filebrowser and then call the menu) but this needs an additional button press when leaving, because you are first returned to filebrowser and have to go to WPS from there. Maybe this isn’t needed anymore because you have the “resume playback” in the root menu - but I don’t know if I imagine it right at the moment, needs a re-thought.

A second thing which clearly seems like a bug to me (and a strange one too): under certain circumstances the “browse xyz” screens don’t work properly. This is what happens _only_ when I enter them from WPS via the filebrowser > root menu (if I don’t go that route they seem to be alright) - I can enter the actual browser correctly but when I go back with “left” without selecting something, I’ll get a blank screen. I have to press “left” once again to get there where I wanted to go. In the “theme browser” this leads to even more confusion as I first get the .cfg files correctly which are in “.rockbox/themes” - when I press “left” from there I get all the .cfg files which are in “.rockbox” - “left” again and I’m back in the settings menu (without the blank screen). Don’t know if this is something Ondio specific…

</novel>

thats not a long post :) I got an email ths arvo from a very talkative friend (and its a group email so its longer than it needs to be) that is going to take an hour to bloody read later :’(
… anywho….

figure out how you want the buttons to work and ill code it that way.
and please explain the browser problem a bit better.. I dont quite understand how to reproduce the problem

edit: didnt see GodEaters post… hmm.. odd :(

The browser problem seems to be exactly the same problem I described earlier. I did some more tests and can reliably reproduce it when the startup screen setting is set to “File Browser”. If the setting is set to “Main Menu” I can’t reproduce it regardless the way I try to access the “browse xyz” entry.

Bluebrother’s finding may explain the problem - seems like it has to do with entering those sub browsers from the filebrowser:
I haven’t set anything else than the root menu as startup screen, the bugs doesn’t occur when entering the browsers from there. But when I want to, for example, change themes while playing music - I have to go from WPS to filebrowser first and then call the root menu (due to the “Settings menu” problem I described above). It will then lead to the strange behaviour when cancelling the “xyz browser” with going left.

As for the buttons: I had a thought about it but realised that understanding the nature of the root menu is also involved. I’ll go on studying the wiki for that and would prefer discussing in IRC later.

… and another one: setting the file view from the quick screen doesn’t work anymore – the setting seems to get changed but not applied. Changing the setting from the settings menu works fine (and the new value gets displayed here, I simply need to enter the menu and confirm the highlighted value). Haven’t checked if that also affects the other quick screen settings.

hmm… I’m in the process of getting a working linux setup going again, so this is me saying im not ignoring the patch.. just not able to fix it yet…

ok, I now dare anyone to point out another bug in the browser!

pixelma: hopefully ill catch you in irc soonish so we can figure out how to do the buttons properly… Also how should the buttonbar act in the root?

   root_menu.patch (46.3 KiB)

and this adds the keymaps for the iriver remotes (I only have the h100 lcd so havnt checked it on the other 2).
so, the keymaps that are good to go are:
iriver hxxx
x5 (doesnt have ACTION_MENU_STOP )
e200 (doesnt have ACTION_MENU_STOP )
h10 (doesnt have ACTION_MENU_STOP )
ipod (not tested on target, but should work)

   root_menu.patch (48.2 KiB)

Hi,

This latest one doesn’t compile for H120 - the patch applies OK but fails with the following errors:

CC bookmark.c
In file included from bookmark.c:38:
recorder/icons.h:30:25: rockboxlogo.h: No such file or directory
recorder/icons.h:32:32: remote_rockboxlogo.h: No such file or directory
make[1]: * [/home/user/rockbox/build/apps/bookmark.o] Error 1
make: * [all] Error 2

Should rockboxlogo.h and remote_rockboxlogo.h be in the patch? Unpatched SVN compiles fine, and I can’ find rockboxlogo.h and remote_rockboxlogo.h in SVN. This is all in VMWare image 4.

Cheers,

Alex

The same here.

Also it seems this patch doesn’t create:
root_menu.c
root_menu.h
as it should do (because they ar missing when compiling)

Also Icon_Rockbox should be defined in rockboxlogo.h (which is missing from the patch)
I’ve made some changes to the patch (see it as some kind of proof of concept) that works with svn.

http://rockbox.schoorl.nu/root_menu.patch

It compiles with 2 warnings about recording (which seems to work well) Both Database and file view is working as far as i can test on a 5g.

doh…
*_rockboxlogo.h is generated in the build so dshouldnt be in the patch.. try a make clean and reconfigure if it keeps happening… What changes have you made?

oh, root_menu.* can be taken from the last patch I uploaded with them.. no changes have been made there since.

Jonathan Gordon:

I have a rockboxlogo.h now (don’t know why :|)
i’ve added root_menu.* to patch, then it still fails at:

CC root_menu.c
root_menu.c: In function ‘browser’:
root_menu.c:62: warning: ‘filter’ may be used uninitialized in this function
root_menu.c: At top level:
root_menu.c:241: error: ‘Icon_Rockbox’ undeclared here (not in a function)
root_menu.c:241: warning: missing initializer
root_menu.c:241: warning: (near initialization for ‘root_menu___.icon’)
make[1]: * [/cvsroot/rockbox/build/apps/root_menu.o] Error 1
make: * [all] Error 2

Changes in the ‘patch’ i edited was your last patch:
I added root_menu.* to patch
I’ve changed the line Icon_Rockbox to Icon_Bookmark (in root_menu.c, Icon_Rockbox isn’t defined in rockboxlogo.h
but i can’t trace where it ‘should’ be defined)
and now it compiles with the following warnings:

CC root_menu.c
root_menu.c: In function ‘browser’:
root_menu.c:62: warning: ‘filter’ may be used uninitialized in this function
CC screens.c

CC recorder/icons.c
recorder/icons.c:82: warning: excess elements in array initializer
recorder/icons.c:82: warning: (near initialization for ‘bitmap_icons_6x8’)
CC recorder/keyboard.c

even with those Warnings everything seems to work just fine and root menu works as it supposed to do.
I don’t have the problems i’ve had with some previous patches :)
But this is just some sloppy work from me to get rootmenu working here, and maybe it’s usefull to others :)
But i will try to find where Icon_Rockbox should be defined.

Regards,
William

hmm… Icon_Rockbox should be in recorder/icons.h.. if it isnt the patch must not have applied cleanly… attached should work fine.

   root_menu.patch (60.4 KiB)

pixelma: hmm the ondio really lacks buttons :(
Its up to you how we handle it.. but I found the reason why he context menu doesnt goto the root instead of the main menu, which is now fixed in the trees and wps.

So, do you want to use the mode (?) button to always goto the root? or leave it as is and 2 long presses to get to root from wps (and left from browsers to get there)

the patch btw adds 2300bytes to the ondio SP… which imo is ok :p

   root_menu.patch (62.9 KiB)

Thanks, latest patch compiles (against 12499 at least). However, follow playlist isn’t working - on H1x0 pressing Navi in WPS takes me to where I was previously in the file tree, and not to the directory in which the currently playing track is. I’ve tried with an unpatched version of 12499 and it works fine with that, so I suppose the root menu patch must be introducing the problem. Other than that, all seems good!

Cheers, Alex

fixed and synced.

   root_menu.patch (63.6 KiB)

ok, lets commit this one?
All keymaps are done except x5,e200,h10 dont have ACTION_MENU_STOP.

   root_menu.patch (53.8 KiB)

grr…

   root_menu.patch (66.3 KiB)

3rd time lucky… Hopefully there are no warnings on any target now.

   root_menu.patch (66.4 KiB)

Not quite there yet; follow playlist only takes me to the folder, not the playing file.

ok.. Grrr….
attached fixed the resume problem. BUT its 1am here so its possible I’ve put in an accidental bug.. so be on the lookout for the wrong item being selected if not resumeing from wps…

NOW.. we have 2 things to argue about before we commit..
1) Exiting from the wps, should it put you in the previous screen, or the root? I say root..
2) going into files/database from the root menu, should you resume your position in the tree? or start from / ? (I thought we already agreed on resuming tho? )

If we really cant agree then im going to say stuff it and add 2 more options…

(this patch also fixed the ondio keys)

   root_menu.patch (68.8 KiB)

That’s much better, thanks.

For your other questions:
(1) Do you mean after STOP? If so, I’d go to the root if follow playlist is off, or the previous folder (with last played file selected) if follow playlist is on. If you mean the MENU/SETTINGS button, it should just go to the root.
(2) I prefer if this goes to the files/database root folder - otherwise it doesn’t feel like a proper heirarchy. With follow playlist on it’s easy to select Resume/Now Playing first to get back to the resume point.

I may not have understood the questions, of course!

1) My suggestion: STOP goes to the root menu, as well as MENU.

2) We have already agreed upon remembering the position. It would drive the user nuts to always have to start from the root when reentering the browser.

I would expect it to work the other way around…

1) I don’t like that when stopping leads to the root menu, it introduces additional navigation. The user would have to move down to files/database first, then start the procedure of selecting a song. It only makes it easier for those who often change between using filebrowser and database.

2) I thought I remembered it’s been discussed and sorry for jumping in a bit late but it really surprised me when I found out that this is how it works. It drives me more crazy to enter filebrowser with “right” from the root menu and immediately have to go “left” because I’m in some subdirectory - this seems illogical and thus unintuitive to me. I don’t think that it is easier (and less pain) when one has to navigate from the current subdirectory to another one - at least having to go one or two levels up and then down again - in comparison to go three (or so) levels down from the root directory… especially when coming from the root menu.

My suggestion:

1) STOP should bring you to the folder with the currently playing song selected if follow playlist is on and bring you to the folder with the last played (ie. selected from the file/database browser) song selected otherwise.
2) Go to the root folder, but with the “current” folder’s parent selected. The correct sub-folders would also be selected so that continually pressing right/select will eventually bring you down to the remembered position.

A suggestion for 1. (which also was my first thought): make it dependent on the “startup screen” setting.

This way the newbie will always see the root menu, someone who often switches between filebrowser/database for podcasts, watching photos/videos will have it easier when starting from root menu, too. The user who has decided on whether using filebrowser or database most of the time will also be returned to his favourite screen.

I agree about 1) taking you to the browser with the folder/file selected.

Marianne,

It probably drives you crazy because you imagine the root menu as the parent of the root folder of the browser, and that the Ondio uses the Right button to select. Other targets use the Select button to select from the menu.

I often browse to a location in the tree and then press Menu to change an option or two (taking me back to the root menu). When I then reenter the browser to continue, I don’t want to come back to the root, I want to continue browsing where I was. I think that always starting from the root would be awfully inconvenient in most cases.

JdGordon: I just found time to try the patch and I like it a lot :)
There are just a couple details I think should be corrected before you commit :
- There are two “playlist options” menus. The first is in the root menu and the second in the settings menu. I think the second one should be moved somewhere in the “general settings” submenu, maybe as an entry of it’s own between “playback” and “file view”. It should also lose the “options” part and become something like “Playlists” for consistency. The first one can probably stay as it is.
- Why isn’t there a menu title to the plugins list ? It would look better and more consistent if there were one.

I agree with pixelma.

Isn’t the intention that the root menu is part of a heirarchy, above the file browser and database as well as incorporating the settings? If so, then it only makes sense for 2 to go to the root. I like Barry’s idea, but suspect it would open a new can of worms and perhaps feel inconsistent.

No, the intention is not at all to make the root menu part of the file system hierarchy. It is an entry point to the different functions, among them is the file browser.

After some discussion in IRC I could understand (2) a bit better - maybe I could get used to it…

As a side effect of the discussion, a bug could be discovered: I wasn’t aware of “holding” left in the filebrowser should go to the root directory from any subsubdirectory - because it doesn’t work on Ondio ATM. I can only go one directory up at a time.

Edit: adding some accuracy… I actually have to release the button before I can go up to the next directory level. I understood that it shouldn’t go directly to the root - but ‘skip’ through the directory structure repeatedly until root directory is reached.

I had a chance to test the root menu in the sim.
I really like it! Espesially that the menu remembers the last position is very clever.
I would suggest to put sleep timer in the new System entry in the root menu.

It would be nice to get rid of General Settings. The entries of the general settings menu could all go one level up.
This is my suggestion for the first settings level:

Sound
Playback
File Handling (this inludes File View + Database + Playlist Options + Bookmarking)
Display
System (should be named differently to avoid confusion, better get rid of this entry completely somehow)
Language and Voice
Recording
Manage Settings and Themes (Themes and Settings are essentially the same…)

This gives us 8, maybe 9 entries and reduces one level of complexity. This is maybe too much to do with the root menu patch and should be included seperately.

ok, Ive read this thread and the parts of last nights IRC log that I found and I tihnk everyone is falling in line? (Ill re-read to make sure Ive got it right..)
But stuff I wanted to mention.

pixelma: “As a side effect of the discussion, a bug could be discovered: I wasn’t aware of “holding” left in the filebrowser should go to the root directory from any sub directory - because it doesn’t work on Ondio ATM. I can only go one directory up at a time.” ← thats a keymap issue and I fixed it…

Linus: who are you agreeing with in Tuesday, 27 February 2007, 08:46PM ?

Nicolas and Rincewind: it was said in irc but ill say it here again in case you wasnt there… The aim is to get this commited first, then we can move menus around to make them more logical.. as long as the root menu is mostly correct. (edit: screw it.. attached patch renames playlist options and moves it into general settings)

OK, it was suggested in irc, so now its in… If you goto the file browser from the wps and follow playlist is on then it will goto the current track. but even if it is on, if you enter the file browser from the root menu it will resume at the last location.

   root_menu.patch (69.7 KiB)

I was agreeing with Barry about STOP taking you to the browser. However, I think it should behave like it does today, i.e depending on the follow playlist setting.

then I think im alone in saying stop in the wps should always goto root,
After this change does anyone have any other bugs which stop me from commiting?

actually.. now I’m confused. how can stop be dependant on the follow playlist option? that option only works if music is currently playing. Pressing stop (obviously) stops music first, so regardless of that setting it should put you in the last directory the tree was in (which is likly the one with the current track, but not certain)

I’d actually rather STOP return me to where I launched the playlist from. To me, follow playlist is really only useful during playback at least. Once I stop, I’d prefer to return to the location in the filetree I started playback from.

Actually, that’s not _quite_ right. If I launch from a playlist, it makes sense that when I close the WPS, I return to seeing that playlist. If I launch with folder play, there’s no association in my mind to where I should be when I return (though it does lean toward follow-playlist style behaviour in that sense, showing whatever folder / virtual ‘playlist’ is currently active immediately before stopping).

Well… the day has come… except for some reason the link between me and svn.rockbox.org is down somewhere in Singapore. So any bugs mentioned between now and some time tomorrow will get fixed, otherwise we commit as is.

There is one massive problem tho, only 2 or 3 of the items in the root are currently voiced,

I caved in… stop in the wps takes you to the previous screen… this is final.. I cant be bothered argueing anymore :p

   root_menu.patch (71.9 KiB)

after thinking a bit about the stop issue:
pressing stop from the wps is kind of a special situation. Why not go back to the screen the user selected as startup screen (preserving the state for file / database browser)? Sounds much more logical to me: a user who sets the file browser as startup screen most likely will want to use that as next step (and in that case the behaviour is the same as current svn does). A user setting the Rockbox menu as startup screen most likely will want to use that as next step.

And a user that set the Recording screen as the startup screen, or the FM Radio?

we could either use the RB menu instead, but when thinking about it I don’t consider this a problem – a user who usually uses recording shouldn’t be surprised by this, should he? Just imagine a taper who just want to make a short check of an audio file. Returning to the recording screen after stop would make much sense in that case.

The only point where this wouldn’t work is with the wps as startup screen. In that case we need to default to the last screen or the RB menu.

It seems to me that when I close the WPS (stop, or whichever button banishes it while maintaining playback) I should be where the WPS was invoked from. It makes sense to me, at least, as I still see the WPS as a screen you invoke from somewhere, that shouldn’t have the power to move you someplace else. Like, for example, when you double click a media file to launch a media player on a desktop, when you close it, you expect to find, beneath it, whatever was there when you launched it, not something completely different.

My link to svn.rockbox.org is still down, so unless I can get wireless working at uni this arvo (or Tor working tonight) it will wait another day for commit :’( (which I really dont want to do, because it seems there is a 30min convo on irc every 12 hours or so :p )

anyway, there was some talk about follow playlist with the DB? iirc it doesnt keep a psuedo path so unless that happens we dont have as much flexibiliy as we have with the file browser. So wps > DB should always put you in the last db dir you were in. and select in wps should take you to the last browser (file or db), if its not doing that then its a bug which needs fixing.

Can someone please make a voice file for this patch? I cant get the configure script to work :(