• Status Closed
  • Percent Complete
  • Task Type Patches
  • Category User Interface → Themes
  • Assigned To No-one
  • Operating System All players
  • Severity Low
  • Priority Very Low
  • Reported Version Daily build (which?)
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by jdgordon - 2008-10-12
Last edited by jdgordon - 2010-06-03

FS#9477 - new WPS tag: %mo (view mode!)

This 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.

Closed by  jdgordon
2010-06-03 04:18
Reason for closing:  Out of Date

Do I understand this patch correctly? %mo is a tag that returns the current view mode (your description says it “lets you change the view mode”). Pressing ACTION_WPS_BROWSE actually changes the current view mode, overriding the existing “go to browser” behaviour.

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.

yes your correct.
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)

This sounds as it will complicate things – what should users expect ACTION_WPS_BROWSE to do? How should a user know a theme is using this tag? While it could be used for more fancy themes it also adds complexity and inconsistencies. Just think how you want to describe this feature in the manual – “Press select to go to … sometimes the browser”? I bet most users will get confused about this.

the manual would say something like “NOTE: some custom WPS’ may include a tag which would change the browse button to a “change view” button. If this is the case you need to go through the menu to get to the files”.

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.)

remember that some people like to change their themes frequently, and having buttons behave different depending on the used theme (as far as I understood this will then also depend on the number of modes used) isn’t a good idea IMO – we want buttons to be consistent, and this makes it more inconsistent.

thats not our problem… if they go changing themes they understand what may happen… As long as the supplied WPS’ work as expected its fine.

fml2 commented on 2008-10-12 09:56

This seems very related to custom key bindings (which iirc were frowned upon by the developers)

Why not make %mo|one|two|-| have - be “the old function of the browse button”? Or maybe just have “the old function of the browse button” *always* be the last thing it does (that way you can’t remove the browse functionality, just delay it somewhat, I actually prefer this). That way the use of the button is never changed, just delayed. So you “cycle” through a few WPS alternatives, maybe if you leave it on one for 10 seconds it goes back to the first one, or if you go all the way through to the end you get the normal browse view.

well it has to be the last one because the code which checks the button doesnt have easy access to the values in the conditionals, and I think that having it at the end is even worse than not having it at all.

Another option, as an alternative to giving it a button map, is to base what is displayed by a setting that is only available from the WPS Context menu.

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.

no, the point of this is to quickly change the display.. having to go through menus defeats the purpose of it

You don’t get to say “no” flat out unless I get to say “no” because “having it change keymaps defeats the purpose of my comment.”

You can change the display very quickly if it’s the first item in the context menu, and you’re perfectly aware of this.

I really love what this patch does, but agree with Paul that taking away the old function of the browse button really hurts the way rockbox works. I use that button in conjunction with the follow playlist option to always be able to jump to the folder of the currently playing song. With your patch applied the only way I can do this is by pressing stop. On my sansa e260 long play has no effect I believe it would be a much better choice.

ok, this adds a setting which lets you disable the tag (defaults to disabled so it actually lets you enable the tag)

How about “Enable multi-view WPSs” as the name of the setting?

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.

I am against the setting… but I was also getting the impression that it would only be accepted if the setting was there (although it feels we are going the other way now…)

What about using a button combination? E.g. hold select und click forward/backward to change the WPS view. There’s not much time to click fw/bw before the WPS Context menu appears, but it’s manageable IMHO.

nup, the point is to be able to change the view quickly… button combinations are slow and imo crap

At linuxstb’s request, I’m posting a sort of test theme I made that uses this tag. It’s for the iriver H10 20GB and the iAudio X5, though I’m sure it could be easily adapted for other models if anyone wants to.

This is a theme for the iPod video that uses this great patch, if anyone wants to try it :)

Just for the record, this patch was reverted after being committed to SVN because it is unwanted in its current form - not to “fix yellow” as the revert commit message stated.

This was discussed in depth in IRC today, starting here:

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.

the desire is by the vocal people in irc.. a compromise needs to be figured out

I’m actually with Llorean and amiconn here. Removing the possibility to go quickly to the filebroswer is bad.
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

using a button combo means lots of work trying to find a usable combo for each target. A-B mode and next/prev dir already use play+left/right

discussion started again here: 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.

In this thread you suggested the possibilty of a user configurable setting… If I’m undersatnding it right, one would configure (i.e iPods) if the select button would be used for accesing files (current) or if it would be used for changing the view modes… would that be possible?… and acceptable?

half way up the page is a comment which has the patch to do that. If that was the happy compromise then I would be all for it, but I think that version isnt like either.

You can already quickly switch between two sets of information. This patch is to add even more information.

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?

I’m not saying the information needs to be available quickly, the mode switching needs to be… 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.

I can play the “not an option” game too: Taking away the “quickly get to browser button” is not an option because some people use it.

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.

In this thread you suggested the possibilty of a user configurable setting… If I’m undersatnding it right, one would configure (i.e iPods) if the select button would be used for accesing files (current) or if it would be used for changing the view modes… would that be possible?… and acceptable?

In this thread you suggested the possibilty of a user configurable setting… If I’m undersatnding it right, one would configure (i.e iPods) if the select button would be used for accesing files (current) or if it would be used for changing the view modes… would that be possible?… and acceptable?

I agree with JdGordon that mode switching should be convenient (going through the menu is definitely not) to be useful; but since I use the go to browser function a lots, I’d hate to lose that functionality as well. If I remember correctly, currently there is some complicated button sequence for the random advance folder thingy (can’t remember exactly since I don’t use it); why not map either the go to browser or the change mode to a sequence like long + short select, etc.?

(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).


Available keyboard shortcuts


Task Details

Task Editing