Rockbox mail archiveSubject: Re: jdgordon: r21307 - trunk/apps
Re: 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.
Received on 2009-06-18