On 23/03/06, Brandon Low <[EMAIL PROTECTED]> wrote:
> 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?
im not entirely sure :p i was hopeing this msg would get more responses...
im gonna implement the function today in 1 of my plugins that uses
_pre on some targets and see how it goes..
> 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?
im only worried about the scroll wheel events.. i dont have an ipod so
it might be hard to test it out... but we'll see
>
> 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...
> > >
>
