Great work! You just took some work off of Christi's plate toward cleaning up button definition hell. This is basically very closely along the lines of what we were talking about at devcon for button functions, and by moving the pre logic up to a higher level, we can reduce code size and improve clarity in the button switch loops.
Some questions to ponder: What is our next step from here? Are there some button definitions which are optional or nonsensical on some targets which should be made optional? Where can we implement the _PRE logic so that it doesn't have to be duplicated all over the place, and so that (on ipod) scroll touched events don't interfere with it's proper operation? Thanks much for looking into this, Brandon On Wed, 03/22/06 at 23:05:43 +1100, Jonathan Gordon wrote: > 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 <[EMAIL PROTECTED]> 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... > >
