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
