This is the bug/patch tracker for Rockbox. Click here for more information.
Quick links: Bugs · Patches · Rockbox frontpage
FS#9477 - new WPS tag: %mo (view mode!)
Attached to Project:
Rockbox
Opened by Jonathan Gordon (jdgordon) - Sunday, 12 October 2008, 09:05 GMT+2
Last edited by Jonathan Gordon (jdgordon) - Thursday, 03 June 2010, 06:18 GMT+2
Opened by Jonathan Gordon (jdgordon) - Sunday, 12 October 2008, 09:05 GMT+2
Last edited by Jonathan Gordon (jdgordon) - Thursday, 03 June 2010, 06:18 GMT+2
|
DetailsThis patch adds a new tag %mo which lets you change the "view mode" of the wps.
%mo<one|two|three|...|> means that it will start with "one" displayed. pressing the usual browse button (usually select) changes to the next mode eventually getting back to the start. There is a limit of 127 view modes which could be bumped to 254 if we change to unsigned char. If the tag is not used then there is no change to the browse button behaviour. (also, if there is a remote + remote lcd then pressing the remote's browse button should only change the remotes mode... untested though) This is ready to commit except I'm not sure if we want to complicate it at all with timeouts or other stuff... I'm thinking not. 
wps_view_mode.patch
(5.2 KiB)
gwps-common.c | 10 ++++++++++ gwps.c | 27 ++++++++++++++++++++------- gwps.h | 7 ++++++- wps_debug.c | 3 +++ wps_parser.c | 14 ++++++++++++++ 5 files changed, 53 insertions(+), 8 deletions(-) |
This task depends upon
Closed by Jonathan Gordon (jdgordon)
Thursday, 03 June 2010, 06:18 GMT+2
Reason for closing: Out of Date
Thursday, 03 June 2010, 06:18 GMT+2
Reason for closing: Out of Date
I can see this in combination with conditional viewports could create interesting WPSs, but am not convinced it's worth sacrificing an existing action for - especially as many targets are very short on buttons. I don't think the suggestion you made in IRC to go "Mode 1, Mode 2, ...., Browser" will work nicely either - it will break the "rotate through modes" feature, and also make it a pain to go to the browser.
As for stealing the browse button... yes but its ONLY if you actually use a theme which uses this tag... If you don't want it then you will never see a difference.
Also, I'm open to suggestions as to which button to steal, browse just happens to be the most "useless" one and the one which is on 99% of targets. (by useless I mean you can get to the browser through the menu anyway)
Once again, this will only affect people who's themes include the tag (I could of course add another setting which will never allow the tag to work (so it will always show the first value) but that sucks.)
If your WPS has the %mo tag then, by default, you can change it with the setting "WPS View" which will have options (one, two, three, etc) and appear in the top list of the WPS context menu is %mo is present. Then it's "hold select, tap select, scroll." A little more than tapping select, but at least it doesn't change anything fundamental about how Rockbox works.
"normal" Themes really, really, absolutely should not be able to change the expected keymapping like this. And saying "Well it's their responsibility" doesn't work when half the themes that have this feature aren't even gonna describe it to the end user.
You can change the display very quickly if it's the first item in the context menu, and you're perfectly aware of this.
However, I'm not convinced about the benefit of such a setting - if the user doesn't want to use multi-view WPSs, they don't have to. (JDGordon - you even said yourself that the idea of this setting sucks in an earlier comment on this task...)
I'm also not convinced by the argument that users wouldn't understand the cause of the "select" (or whatever) button no longer taking them to the browser - they will see the WPS change when they press that button. The manual could describe this button along the lines of "switch view in multi-view WPSs, or return to the browser in single-view WPSs".
Whether or not the user likes that is a different question - if they don't, then they simply use a different theme.
I agree about the problem of inconsistency, but that's always been a problem - we simply don't have enough buttons for a completely consistent UI. so it's a compromise between adding new features and maintaining consistency.
This was discussed in depth in IRC today, starting here:
http://www.rockbox.org/irc/log-20081116#10:16:04
If I understand the discussion correctly, the desire is to find a way to implement this feature whilst still keeping the "go to browser" shortcut, not replacing it.
I'd like to see a button combo, which doesn't only allow you to go forwards through the view modes but also backwards. I could imagine something like play(or some other free modifier)+left/right
seems everyone is against a button combo for this, but still like the idea of a single "next mode" context menu option. I'm still dead set against this because one of the main benefits of the tag is to show different info *quickly*. at least with the named list you can jump to the screen you probably want in one step through the menus, but with a single next mode option its ~1.5s for each mode which is way too slow to be useful.
If something needs to be available *quickly* either put it on the main screen, or on the "hold" screen. Or do you honestly think that there's three WPSes worth of information that needs to be toggled between *quickly* and is USELESS if accessed slowly?
Yes I think this is useless without quick switching. Why would people bother setting up fancy modes with next track info, bitrate, I dunno what else, over more than 2 modes if it takes as much time to change to the next mode as it would to flick through every mode and go back to whatever they were doing?
How about this... song is ending and you want to know what the next track is.. with a single button press you can find out and make a decision on if you want to skip the track (or change playlists entirely), but if I have to go through the menu anyway its faster to go into the playlist viewer than it would to find the right mode (which might be more than one menu entry away)
Putting info on the "hold screen" is not a option because some people set backlight to off on hold.
Personally, I'd use it if it took long, so clearly it still has its uses for some people. You're really going to have to accept that not everyone sees this as a ONE USE ONLY patch, and sees other uses for it as well, so we're not going to accept your terms that "it only can be used for one thing" and think of it instead for all its possible uses.
(On the other note, a playback context menu item for going to filebrowser where the nowplaying file is located is generally useful too (if not solving the problem here), since one might want to see the file even if the playback is started from the database - in which case the select button sends back to the database rather than the file browser).