> My choice would be for having an option too, even if it's just "Insert" or > "None" (although I wouldn't personally object to other functions). > > I have a (naive?) way of thinking of the Rockbox keymap. I'll try and > summarise as a table of "KEYS" which are then mapped to physical keys on a > given target. > (each row is KEY - action in general (action in WPS) > > UP/DOWN - navigate (volume) > LONG UP/DOWN - navigate (volume) > LEFT/RIGHT - navigate (track skip) > LONG LEFT/RIGHT - navigate (rewind/ffwd) > SELECT - select current entry (return to browser) > LONG SELECT - display context menu > PLAY - return to WPS (pause/resume) > LONG PLAY - reserved as a shift key* > STOP - stop playback > LONG STOP - power off* > MENU - toggle between main menu and previous screen > LONG MENU - toggle between quickscreen and previous screen > > * depending on hardware limitations > > This covers basic functionality, excluding plugins and the "shifted" > functions (dirskip, A-B repeat, track properties, pitch screen). None of > this would ever be configurable, so support should be reasonable. It > requires 6 buttons, which is fine for the Ondio (is that the worst case?). > > Then - for targets with more buttons F2/F3/REC etc. we allocate a USER > button that *is* configurable, defaulting to the following: > > USER - do nothing > LONG USER - record > > Hopefully such a simplistic view would be generally usable on all targets > and would help lead to consistency across the UI and across targets.
Hmm, no response at all? I thought this was a useful post. I guess it's either non-controversial, or too stupid for words... Allow me the one bump, please. ;-) pondlife
