Rockbox

I like this idea in general. Consistency is a good thing.

One thing I’ve noticed is that in the WPS you have to press right to go back to the Browser. I think it would make more sense to use Left for this.

Also, the quickscreen is a bit strange. I understand the reasoning behind using FF and REW, but given the positioning of the text on the screen, it’s a bit counterintuitive.

It would be nice to be able to access pitch and id3 screens with just one button press if possible. Maybe one of them could be a short press on right if it was no longer to mean back to Browser?

One last thing which annoys me with the current keymaps too is that in the context menu, pressing back always brings you out of the context menu altogether, rather than just up a level.

“One thing I’ve noticed is that in the WPS you have to press right to go back to the Browser. I think it would make more sense to use Left for this.” You’re right. My reasoning for choosing Right instead of Left was that going to the browser was a “browse” action rather than a “go back to browser” action, but it is a little counter-intuitive.

“Also, the quickscreen is a bit strange. I understand the reasoning behind using FF and REW, but given the positioning of the text on the screen, it’s a bit counterintuitive.” I think it would be better to rearrange the layout of the quickscreen to make shuffle and repeat be displayed next to the FF and RW buttons. IMHO, suddenly making “←” act as “left” is counter-intuitive. I was surprised by the behaviour of the quickscreen when i first tried rockbox on the H10 and it took me some time to understand how it worked.

“It would be nice to be able to access pitch and id3 screens with just one button press if possible. Maybe one of them could be a short press on right if it was no longer to mean back to Browser?” I agree, but we should be careful not to make the pitch screen or ID3 screen more important than the context menu in the WPS. Maybe make a short press of right display the context menu and a long press display the ID3 screen.

“One last thing which annoys me with the current keymaps too is that in the context menu, pressing back always brings you out of the context menu altogether, rather than just up a level.” That’s not a problem with the keymaps, actually, but one with rockbox in general.

Another couple of observations:

1. When you go into any of the debug screens, there is no way to exit. None of the keys work. We need a key mapping for this. I suggest back/left.
2. Long hold of Power is used for turning off, but the menu flashes up when you press Power too, so you always get the menu flashing up when turning off. requiring BUTTON_REL for the menu will probably fix that.

I updated the patch slightly. I changed it to be left to go to the Browser from the WPS. I also fixed the Power off show the menu bug.

The quickscreen still needs to be changes and I haven’t found a solution for exiting the debug screens.

I was thinking again about the ID3 screen. Making it a long press and context a short press would break the consistency of the context menu between browser and wps screens. For that reason I’ve left short press of right doing nothing. Maybe there is a better solution?

   h10_keymap_v2.patch (9.2 KiB)

Another problem. Screens with button_context_settings_r_is_inc (eq, time, colourpicker) trigger twice with Right and Left, once for the settings change, the second time for OK/Cancel.

So, this could already be in here somewhere, but I couldn’t find it in feature requests..

how about changing the keymapping strategy altogether. Basically just define the number of available keys per target and possibly some special keys (like scroll wheels, which behave differently from normal keys) and then define default actions for menues (like back, forward, pgup, pgdown, …). Then have a config file somewhere that provides a default mapping between actions and buttons (actions can define what kind of key they are supporting, like FF/REW supports both click button and scroll wheel, but a SELECT action might just support a click button). Then you also have a config menu end entry screen that let’s users change any mapping they desire (for rockbox itself but also individually for each plugin).
This would:

- Follow the “all customizable” paradigm of rockbox
- Allow people to decide what’s intuitive for themselves
- Make it easier to get better consistency (e.g. some plugins use different keymaps. If you change assignment in one place everything else has to be reprogrammed… instead of simply remapped via config
- Allow plugins (specifically games) to have a common way to map keys
- Get rid of much of the #ifdefs in plugins and possibly elsewhere, because the number of constants is reduced
- Make it much easier to include new hwardware targets. All you need is to define the number and type of keys available in one central location and write some nice config files

I haven’t looked at the source code long enough to know how difficult this would be, but it seems it’s doable and could be quite advantageous.
Just my 2c worth

Ok, just saw that there is already a action→key mapping mechanism (should’ve looked at the patch first . Points about using config files (instead of hardcoding) and having online access to change config still valid though, particularly for plugins, which sometimes seem awkward to control.

The action mechanism is a very recent addition to Rockbox, and seems to be working well so far. I’m not too sure about the config files. Would it not be better to just decide on 1 good mapping and use that? Anyway, that’s out of the scope of this bug.

So, here’s the latest version. Just the problem of not being able to exit the debug screens remains.

   h10_keymap_v3.patch (12.7 KiB)