|
Rockbox mail archiveSubject: user editable keys binding schemes wanteduser editable keys binding schemes wanted
From: <phil_at_x-phobie.de>
Date: Mon, 30 Sep 2002 16:58:24 +0200 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 Received on 2002-09-30 Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy |