|
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 > event. > > > /Fredrik > Received on 2006-07-18 Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy |