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: half-idea for #ifdef and key deifnition hell...

Re: half-idea for #ifdef and key deifnition hell...

From: Jonathan Gordon <jdgordy_at_gmail.com>
Date: 2006-03-22

ok, ive done more playing with buttons..
http://users.monash.edu.au/~jdgor1/rb/button_list.txt is a list of
every unique button definition in the source (excluding the plugins)
(its possible i missed a few but that shouldnt matter)
http://users.monash.edu.au/~jdgor1/rb/suggested_button_list.txt is the
list of bassically all the buttons that are used... i think... if all
these are defined for all targets (along with _pre) and smarter button
handling (like my suggestion) is implemented then there it should be
much easier to pick a button for a screen.. the items with * are not
nescacerily neded.. but might be better to have than not. and the ones
with ? im not sure what they are for.. and i wasnt sure what to do
with the last 5 defines so i left them there...

so with this list of about 20 keys that should be defined for all
targets i think it would make it generic enough...

only problem is with the remote control defines.. but that could be
fixed by doin a #ifdef has_remote around the block for all the rc
keys... i think....

doing this list, im not sure that my last msg is actually needed now..
or the button function would just return standard values for the
generic buttons or something? this would allow ppl to define their own
combos with much less fuss than now...

On 22/03/06, Jonathan Gordon <jdgordy@gmail.com> wrote:
> hey all,
> ok, so i had a few min on the throne before and i was thinking about
> how to make the keypress code nicer (and get rid of those bloody
> painful _PRE definitions..)
>
> ok, so just remember, this idea isnt 100% done and prob has flaws, but
> thats why im putting it on the list.. so we can argue about it and
> make it workable..
>
> so, my idea is to sort of emulate the menu code...
> youd have something like
> struct {
> int button_code;
> bool needs_pre;
> int ret_code;
> function* function_to_call;
> } Button_Choice;
> where cutton_code is the #define of the button you want to get,
> needs_pre will check that the last button was the _pre definition
> (which in this would be the array item prior to this one), ret_code
> would be the value to return, ill explain the reason in a sec, and
> function_to_call is the function to call when this key is pressed
> (instead of having a switch afterwards), this would of course be
> skipped if its NULL;
>
> so, then youd use it something like
> static struct Button_Choice [] {
> { GENERIC_LEFT, 0, 1, NULL},
> { GENERIC_RIGHT, 0, 2, NULL},
> { GENERIC_ENTER_PRE, 0, 3, NULL},
> { GENERIC_ENTER,1, 4, NULL},
> ...
> };
>
> then, instead of calling button_get() or whatever it is, you call
> another function do_button_choice(struct Button_Choice *buttons, int
> num_choices, int &last_button, int time_out) where last_button is used
> to store the last_button so the _PRE things work, we could use a
> static variable here, but this way means we can call it in a "nested"
> sort of fasino... although, just typing this now, im not sure this is
> needed... and timeout sets the button timeout before returning...
>
> in that function it would call get_button with the timeout setting..
> if get_button returns BUTTON_NONE then the funciton immediatly returns
> BUTTON_NONE also. otherwise it goes through the list and if the button
> that was pressed is in the list it checks if it needs _pre, if it does
> and the last button was not pre then im not sure what it should
> return.. (maybe it should keep going through the list and check if the
> same definition exsists but without needs_pre? otherwise return
> BUTTON_NONE or BUTTON_UNKNOWN or something?).
> if the button is found (and if it needs _pre and it was the last
> button) if it has a function to call it returns that functions return
> value (or not?) otherwise it returns that items ret_code value.
> now the reason we need that and not do like the menu and just return
> the item index is so we dont have any #ifdef 's in the switch but can
> still use them when adding items...
>
> does this sound workable? would it make life easier and actually be a
> good replacement for the current system?
>
> my only concern is that it may not be fast enough... but if its not,
> then where key press speed is really needed (i.e games), they can call
> get_button() manually...
>
Received on Wed Mar 22 13:07:40 2006


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