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



Rockbox mail archive

Subject: user editable keys binding schemes wanted
From: phil_at_x-phobie.de
Date: 2002-09-30


Hi

We have a configurable wps, internationalization, selectable fonts but
what is really missing are user assignable key binding schemes. But we
need that. Different users have completely different jobs for their
jukeboxes that require completely different key bindings for ergonomy.
A musician who wants the jukebox for quick practice recording /
rehearsal might want quickkeys for different recording modes and
doesn't care much about playlists and shuffle. A player user might
want different key bindings when jogging to control the unit blindly.
How will he detect wether he accidently entered the menu. While you're
editing playlists you may want quick acces to a 'play intro' feature
(which doesn't exist yet:)). And finally there is of course my
favorite: mp3 file splitting!

The concept in short
It shouldn't be that problematic to have key binding schemes. When you
think about it you find that all keys trigger some kind of action. So
from a naive point of view we only have to go over all those switch
(button) thingies spread over the source code and wrap the case
thingies into functions. All these functions go into a great big entry
table. Then it is easy to read the key assignment from some kind of a
configuration file and map the keys to functions.

The actions
Many actions require parameters. At first glance it seems to me that
we can divide the functionality in 3 classes:
1.) trigger an action
    no parameter needed
    1 command needed
    no value access needed
    no range restriction needed

2.) control a numerical value
    needs two commands: get the value and set the value.
    we need range restrictions here.

4.) control with text value
    needs only one command that calls a text editor (I remember that I
    read that someone already progammed one) and passes the value.
    In the browser the currently selected file name may be passed as
    value.
    We need access to the text value so we can initially display it
    in the editor
    We might need length restriction
    

For accessing parameters I'd prefer the use of getter and setter
methods because that gives us extra flexibility - for example to
determine the value dynamically.

All these 3 classes can be described with a struct like

struct action {
    char *name; /* name of the action */
    int type; /* ACTION or VALUE or TEXT */
    int next_key_scheme /* next key scheme to use */
    void (*action)(void); /* NULL if type != ACTION */
    int (*get_value)(void); /* NULL if type != VALUE */
    void (*set_value)(int value); /* NULL if type != VALUE */
    void (*get_text)(void); /* NULL if type != TEXT */
    void (*set_text)(char *value); /* NULL if type != TEXT */
};

(don't care about next_key_scheme yet, I'll explain it later)
A preprocessor macro could be made to register an action. This macro
could make a table of all actions available. Consider something like:

register("play" , ACTION, mpeg_play, NULL, NULL, NULL, NULL);
register("volume, VALUE , NULL , mpeg_set_volume, mpeg_get_volume,
NULL, NULL);

The configuration file
It could be a plain ascii file that maps key numbers or key names to
the different actions. Maybe we need _many_ names if we want to take
account of all possible combinations, release events, double clicks
and so on. But it could look like that:

button_play : action(play)
button_up : inc_value(volume)
button_down : dec_value(volume)
button_f1 : set_value(volume, 70)

Context sensitivity
You might argue that this concept is very static which conflicts with
the fact that for a good ui we need the same buttons to have different
mappings depending on the context. Example: while the jukebox is
playing back hitting the off key should stop the playback. But when
the machine is stopped hitting off should turn off the unit. It would
be quite a waste to make a complete new scheme only for this little
context switch. But we could get around this problem if we introduce a
kind of inheritance. We can give the key scheme a name. Let's say we
have a complete key scheme for playback that has the off key assigned
to mpeg_stop. Now we could define a new key scheme for
jukebox-is-in-stopped-mode with the off key assigned to do what it is
labelled. Instead of defining a complete key scheme we could say: Use
the playback key scheme but overwrite the off key assignment. This way
we could handle many key schemes within a relatively small amount of
memory. For each context that requires another functionality of keys
we simply make a new key scheme. That's why I introduced the
next_key_scheme in the struct above. Each button event might require
the machine to enter another key scheme. So hitting a button makes the
unit to switch to the key scheme referenced by next_key_scheme. In the
configuration file this would manifest like that:

key_scheme playback-mode
button_stop : action(mpeg_stop)
....

key_scheme stopped-mode using playback-mode
button_stop : action(power_off)

So this is as far as my thoughts for user definable key schemes go. I
know it is a big task that requires massive code changes but we really
need it. I haven't done anything like that before and I might have
overseen details that make this concept collapse. Please don't tell me
"Show me the code", because I won't do any code before this idea has
been discussed. Please comment

Phil



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