Rockbox

Can you make the rec button active in menus other than the recording menu?

I like these changes. Is there any objection to committing them? Presently I find dealing with the main menu from the WPS screen awkward.

JdGordon objects, I like them alot (which goes in line with my posting of this), and I think everyone else is mostly indifferent. He's the main reason I haven't committed them myself.

I think they make it much more usable in general, as well as making it easier to use if you use more than one Rockbox regularly.

I kind of like the buttons mapping the way that it is. Although different than other devices, it matches the labeling on the buttons as well as the functionality of the original sansa firmware.

Have you actually tried this patch for a period of several days to get used to it, and have you used Rockbox on other targets before?

Saying "I like the button mappings the way they are" doesn't mean much if you haven't given yourself time to get used to the alternate. I think these mappings are actually more useful, overall, anyway, and the only label they ignore is the word Menu printed beside the "Power" button, and as the button has a power logo ON it, and they still use it for power, it's not a significant ignoring. All other buttons are actually still used as labeled. It's mostly the alternate (long-press) functions that were changed.

The intent was that the consistency increase is more based on the idea that if you have six targets, and each has a "Select" button, that on each target the select button does the same thing in Rockbox, rather than having "Select" mean one thing on one target, and not be able to do it on any of the others. If it's called the "Select" button by Rockbox, it should do what "Select" does in Rockbox, rather than what select does on this specific version of Rockbox, which is different than another specific version. If you have a Dvorak keyboard vs a Qwerty keyboard, the enter button still does what it does in programs, right?

95% of button functions are identical, so please, spend a week or two trying the patch (not merely a few hours, or even just a day) before commenting on liking the other layout better. You're used to it, we get that, so it's rather unfair to judge this one without acclimatizing yourself to it first, or making an attempt to understand the reasoning behind it. It's not to make it in-line with other targets. It's to make it in-line with Rockbox itself.

I'm also in favor of the changes. My main concerns are that, with the current keys (play=pause, long play=stop) you

a. can accidentally stop playback instead of pause
b. stopping requires a long press. Why that if we could do this with a short one. And stopping playback is a frequent operation.
c. it would be so much more consistent with RB on other platforms
d. SELECT is much easier to press (short or long)

Some might argue that the current mapping is more in line with the original FW. But the UI concepts are so different that it doesn't make sense to try to unify them. Whereas trying to unify keys across RB targets is a very good thing.

So JdGordon, please give in! :-)

a) so? press play again and it will still restart playback at the current position
b) I think ive stopped playback maybe a dozen times in the 19 months ive bee using rockbox
c) again, so? This is nice for people who have heaps of targets, but the majority of users only have one, or even two, which really doesnt make it so hard to remember which key does what on which target
d) short down press is easier than long select imo (and the context menus is something i use frequently)

Regarding point (c), consistency across targets also helps those of us who might try to give advice on the forums etc. but don't own that particular device.

I vote for consistency across targets.

I'm not in favour of forcing consistency across targets, but in my opinion in places where it can be done without harming usability (or if it's a matter of opinion as to whether it does, as some people feel it does and others feel it doesn't) then being more consistent across targets when all other things are (or may be considered barring subjective aspects) equal, then it should be done.

In fact, the Gigabeat did get a similar sort of tweak, a short time after Rockbox was available on it.

Steve: its not so bad now, you can say "press the usual context menu button for blaa" or "refer to the manual"...

I would be happy to have this cmmited if we had the option of using this keymap, or the old one (whic wouldnt be difficult at all to fix up), seen as this is the only tagrte it would affect and we dont care about bin/ram size so much....

So have you agreed on anything (irc or otherwise)? Will it be an option for key mapping? Or has the discussion stuck? I know I can always make a custom build but it is much more convenient to use an official one. I often find myself wanting to use the central button for calling up the context menu.

I've modified your patch Llorean. My version is now a hybrid between the current SVN and Llorean's above. In my opinion these are much better and more ergonomic.

The changes from SVN are:

* The menu button pulls up the menu.
* Context menu is brought up by holding Select.

Forgot to add the file above...

Woops, that last file was wrong, this one works ;)

Bump! Has this any future?

As a new Sansa user coming from h120, I find myself constantly pressing and holding Select to bring up the context menu. I'm not sure I'm fond of the idea of power being stop - I think I like senab's latest attempt better.

Consider this a vote for "Long select -> context menu" and "Menu -> main menu" and *against* "Power -> Stop".

Is there a problem with a short press of "Power" also being stop, or is it just a comfort thing?

On the H120, a long press of Stop is Power, and on the iPods a medium press of Play/Pause is Stop, and a very long press Power, so it just seemed to me that Power + Stop was a good match, rather than Play/Pause + Stop.

Alright, as the only lasting objection to this I've found is really "I'm used to the OF's way of doing things", and because I quite strongly feel that this both increases consistency cross target, increases consistency between a few screens on-target (assuming 'Stop' is analogous to 'Cancel'), and lessens the necessary amount of finger movement in standard operation, I really don't see any good reason for me not to commit this.

That being said, expect it in SVN within the next week or so, or prepare some *new* solid arguments against it. I'm not committing without warning, so here it is, then I'll give a final warning a day in advance. :)

This is the original patch, updated to work with r15336.

Llorean: Perhaps it's just that it seems more logical to me. Having Play/pause/stop in located at the same spot seems fairly logical - makes it the "playback control button". I admit it's different from the other targets though. Perhaps they all need to be changed :-)

Llorean: firstly, I still object and I dont tihnk I've ever used the "I'm used to the OF way of doing it" argument (which would be a lie anyway seen as ive spent a totla of 15min in the OF...)
second, your the one who has argued about the pause and stop functionality being the same, so why give stop a button by itself?

Like I said, im all for commiting this IF it comes with an option...

You haven't used any particularly interesting arguments other than that you think it's a better scheme. In all honesty, what's wrong with "a keymap that more closely matches other targets AND requires less finger movement for common operations"?

As for the stop button, as someone earlier in this thread said, having it on play/pause can be frustrating for people who don't press the buttons quick enough, as for them they can accidentally trigger a stop when pausing, then have the delay of the spinup before being able to resume playback. I don't think there's any *harm* in separating Stop from Play/Pause, is there? It lessens the likelihood of accidentally stopping (since the only other function on that button is "off" which doesn't care if you're stopped or not) when you don't want to, without any "cost" other than making stop less central.

In all honesty, what's wrong with "a keymap that more closely matches other targets" - why should it? the only people this effects are us crazies with multiple targets, and we should be smart enough to be able to switch without thinking too much..
"AND requires less finger movement for common operations" - as the current patch stands, there is no actual "less fingure movement" your replacing a long-up with a long-select...

on the e200 the "spin-up" is a mute point, there is sfa speed difference between restarting from stop or from pause (and with MoB now it should be "simpler" to fix this so if the playlist didn't really change there is no spinup.)

moving stop to power/menu wastes the button AND is more unintuitive to new users than using that for menu, and for right handed people (yes I know your a lefty) is easier to press than down when held)

once again, I'm all for allowing it as an option, but dont force it on everyone

There is less finger movement. As I've requested many times, please TRY the patch for some time before criticizing it. I've removed the need to ever take the finger from the ring of buttons until you're done playback, as the Menu function is no longer on the power button.

And again, when I said "what's wrong with a keymap that more closely matches other targets" my point was "There is a benefit to some people, and you've yet to name a drawback to others." You then just responded with "I can't name a drawback, but since the benefit is only to crazy people, you shouldn't do it." This makes absolutely no sense. It agrees with me: There is a benefit.

How is "Holding Play" intuitive for stop at all? As it is, we use "Power" as a cancel button in several screens, that's equally unintuitive to "Stop" being the power button I think, so I suggest you start removing "Stop = Cancel" from all screens if you think it's as unintuitive as you claim.

I like the keys that correspond well to retailos and what's printed on the case. I have a bunch of targets and don't really have trouble with the differences esp. if the keymap follows the labeled assignments well.

BTW. Long play for stop is also used on X5. Makes sense to me really since it has no stop button. This is actually consistent with such players. An H100 has a stop button and so makes sense to use that for stop.

Long play for stop is also used for ipods (1G2G at least).