|
Rockbox mail archiveSubject: Re: jdgordon: r21307 - trunk/appsRe: jdgordon: r21307 - trunk/apps
From: Jens Arnold <jens_at_jens-arnold.net>
Date: Thu, 18 Jun 2009 08:19:56 +0200 On 17.06.2009, Thomas Martitz wrote: > Daniel Stenberg schrieb: >> On Tue, 16 Jun 2009, Paul Louden wrote: >> >>> I think abortable timed splashes is a recipe for >>> accidental keypresses. >> >> Thinking about it further, I can only agree. The only way >> to safely prevent that would be to use a key that MUST NOT >> be used for anything on the screen following the splash, >> but that'll be a worse restriction than not being able to >> dismiss the splash in the first place. >> So for these reasons I'm switching camps. Let's leave the >> splash as it was. >> > What the current splashes are doing is worse. You can press > buttons, and they'll be processed after the splash in the > sequence you pressed them. So if you pressed some > up/down/select/w.e. combo (in the hope you can cancel it, > or because you're bored or whatever) bad things can happen. Being able to press buttons in advance (without looking at the screen) is one of the major advantages of rockbox imo. A splash within such a sequence would ruin that, as it would make the necessary button sequence timing dependent. That said, it *might* not be that bad, because a button sequence where all goes well *should* not include a splash. If a splash appears, this usually indicates a problem, in which case it might even make sense to eat all queued button events and make the splash *not* go away on those. This is something that would need very thorough testing of all possible code paths. Regards, Jens Received on 2009-06-18 Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy |