Rockbox mail archiveSubject: 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: Wed, 19 Jul 2006 00:00:58 +1000
well, now the freeze has thawed (hoho someone shoot me :p ) can we get
some discussion on this happening?
I reckon the button #define hell should be one of the first things tackled.?
On 29/05/06, Fredrik Íhrn <ohrn_at_chl.chalmers.se> wrote:
> Jonathan Gordon wrote:
> > ??
> > 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?
> Sorry, I meant while-loop, the one inside read_button() that loops over the
> items array.
> > 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??
> It doesn't, the driver will generate a key down event and then a double click
> event soon after, same thing for long press, a key down + long press event.
> It's they way it has to be or all key events would have to be delayed the
> amount of time it takes to detect a double click or long press. This would
> make the UI seem sluggish.
> All other OSes I know generates 2 events and it's not a problem.
> > 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..
> Well, the current "_PRE" handling code could be removed completley if the
> button driver returns (BUTTON_xxx | BUTTON_REL) when a short press ends and
> (BUTTON_xxx | BUTTON_REL | BUTTON_REPEAT) for a long press. An application can
> then easily implement 2 different actions without having to track the previous
Received on 2006-07-18