Rockbox.org home
release
dev builds
extras
themes manual
wiki
device status forums
mailing lists
IRC bugs
patches
dev guide



Rockbox mail archive

Subject: 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.

Regards, Jens
Received on 2009-06-18


Page was last modified "Jan 10 2012" The Rockbox Crew
aaa