Rockbox.org home
release
dev builds
extras
themes manual
wiki
device status forums
mailing lists
IRC bugs
patches
dev guide



Rockbox mail archive

Subject: Re: Custom button mappings - a proposal

Re: Custom button mappings - a proposal

From: Jonathan Gordon <jdgordy_at_gmail.com>
Date: Thu, 22 Oct 2009 13:16:40 -0700

my immediate reaction is avoid the hold button as the modifier.. that
means that only those targets with a software hold switch can use
this...

2009/10/22 Frank Gevaerts <frank_at_gevaerts.be>:
> Hi,
>
> I'd like to discuss a way to support custom button mappings that avoids
> the often cited problems about supportability.
>
> Basically, there would be a setting that enables a specific key or key
> combination to switch to a custom button map. To make things clear, the
> setting itself does not switch, and on boot the default button map will
> be active.
>
> Possible button combinations to switch to the custom map could be:
> a. hold (i.e. hold on == custom map).
> b. switch hold on while holding a specific button (similar to above, but
>   hold itself stays usable)
> c. hold on-off while holding a specific button.
> d. some other unlikely to accidentally hit combination that's not used
>   yet.
>
> I'm undecided whether the custom button map should be the same for all
> screens, or should be customisable per screen.
>
> All standard controls will be disabled by the custom map, including
> touchscreen. They can of course be re-enabled in the map itself.
>
> Thoughts? Questions?
>
> Frank
>
> --
> "Debugging is twice as hard as writing the code in the first place.
> Therefore, if you write the code as cleverly as possible, you are,
> by definition, not smart enough to debug it." - Brian W. Kernighan
>

in practice I dont think that would work... my view is it shuold be a
combination of:
a) a loadable keymap file which can be bypassed at boot (similar to
the way you can reset the settings on boot). This keymap probably cant
be changed during a session. This means its up to the user to make
sure it works
b) add more options in various screens for what actions can work.

i.e right now we have a hardcoded action<->button table, allow that to
be loaded from a file. Then with a list of contexts and actions
available in those contexts the user could do what they wanted... If I
want to open the playlist viewer in the WPS with hold+rec I can do
it...
If I want to use that combo to do something that isnt possible then
I'd write a patch to add that action..

really, thats the only way worth doing it, any other way is a half-measure.
Received on 2009-10-22


Page was last modified "Jan 10 2012" The Rockbox Crew
aaa