From: Jonathan Gordon <jdgordy_at_gmail.com>
Date: Mon, 29 May 2006 18:52:47 +1000

??
first the switch/if..ifelse is just a matter of style.. and the switch
uses 1 less variable.. but it really makes no diff...
which for loop are u talking about?
as for checking for long/short/dbl clicks in the actual button
driver.. how does it know to wait for a double click instead of diong
2 single clicks? or wait for a long press??
doing it this way enables u to use the old crappy _PRE moethd and
#define all your keys.. or use this and have 1 swithc for your button
loop which is neater, cleaner and easier to maintain..

On 29/05/06, Fredrik Öhrn <ohrn_at_chl.chalmers.se> wrote:
> Jonathan Gordon wrote:
> > hey all,
> > well iv had another play with this and i tinhk it actually works :O
> > attached is a demo plugin that just tests the loop.. hopefully its all
> > simple enough to understand without thinking too much..
> > the idea of line 12-35 is that there would be a standard list of
> > buttons that would be global so the button list would really only ever
> > really need to be coded again is if some wierd combo u want isnt in
> > the main list..
> > as u can see. the code easily handles short/long presses of both
> > individual buttons and combo's. fancy stuff like quick double press
> > and short then long press would need to be done after the call.. but
> > that doesnt happen very often so thats no big deal..
> > also, ive only tested this in the sim so i dont know how responsive it
> > feels on the actual player.. (if the attachment doesnt work iv put it
> > at http://members.optusnet.com.au/jdgordy/button_test.c )
> >
>
> Having both a for-loop and a switch case to read a button seems a bit over
> kill to me.
>
> Why not turn it into a if/else if/... chain instead? That loosens the
> contraints of the current switch case style without incurring to much overhead.
>
> Also checking for key up/down, long-press, double clicks etc, should be
> handled by the button driver in firmware/drivers/button.c and set as flags.
>
> Here's a quick sample of how I'm envisioning it:
>
>
> enum {
> ACTION_UP = 0,
> ACTION_DOWN,
> ACTION_FOO,
> ACTION_BAR
> };
>
> #if (CONFIG_KEYPAD == IRIVER_H100_PAD) || (CONFIG_KEYPAD == IRIVER_H300_PAD)
>
> // Maps the actions above to button defines for a specific target.
> // This array could be changed at runtime to allow a user to remap buttons or
> // handle stuff like the 3 different remotes that an iRiver may have.
>
> static action_buttons [4] = {
> BUTTON_UP,
> BUTTON_DOWN | BUTTON_DBLCLICK,
> BUTTON_MODE,
> BUTTON_SELECT | BUTTON_REL
> };
> #endif
>
> #if CONFIG_KEYPAD == RECORDER_PAD
> static action_buttons [4] = { ... } ;
> #endif
>
> ... etc ...
>
>
> enum plugin_status plugin_start(struct plugin_api* api, void* parameter)
> {
> int button;
> rb = api;
>
> button = rb->button_status ();
>
> if (button == action_buttons [ACTION_UP])
> DEBUGF("Up!\n");
> else if (button == action_buttons [ACTION_DOWN])
> DEBUGF("Down!\n");
> else if (button == action_buttons [ACTION_FOO])
> DEBUGF("Foo!\n");
> else if (button == action_buttons [ACTION_BAR])
> DEBUGF("Bar!\n");
>
> }
>
Received on 2006-05-29