From: Frank Gevaerts <frank_at_gevaerts.be>
Date: Sun, 8 Nov 2009 19:47:01 +0100

On Sun, Nov 08, 2009 at 04:30:05PM +0000, Rob Purchase wrote:
> Hi all,
>
> I want to get some discussion going and clarification about the future
> direction of the touchscreen interface in Rockbox. The current situation
> is rather unsatisfactory:
>
> - the user has a choice of two modes: "3x3 grid" or "absolute" (ie. real
> touch mode) in menus and WPS

The actuall presence of a choice shouldn't really be a problem I think.

> - many screens have not yet been adapted to "absolute" mode
> - some of those screens temporarily switch the user to grid mode (with
> no warning), whereas others don't even do that and are unusable in
> absolute mode
> - the default WPS is not set up for absolute mode (at least on the D2,
> since the 320x240 Cabbiev2 is shared with other targets)
> - many plugins currently switch to grid mode, even while in their menus
> (horrible behaviour if the user has chosen to use absolute mode in
> menus).

Those are of course all bugs.

> Work is going on to provide "real" touchscreen versions of some screens
> (eg. the EQ screen - FS#10639) but this raises an interesting question.
> The most intuitive "real touch" implementation of this screen (and I'm
> sure others too) is sufficiently different to the existing one that it
> can't be used in grid mode.
>
> The question is, does Rockbox as a project want to maintain "grid mode"?

If at all possible, yes.

> Even if this potentially means compromising future "real touch" versions
> of these screens? I'm imagining scenarios of the existing screens being
> if()'d and #ifdef'd to hell and beyond if we want to achieve this.

I think there are several options:
(a) the current status quo (i.e. use grid mode in case of conflict).
(b) accept that some screens will not be very usable in grid mode
(c) try to support both in a single implementation. Likely to have lots of
    if() and #ifdefs.
(d) have two implementations for the problematic screens, and call one of
    them depending on current mode

I think (a) is not acceptable, while (d) is the best solution. (b) and
(c) are problematic to various extents.

> I'm firmly of the opinion that "grid mode" was only ever a stop-gap
> measure, and in the long run the user-visible option should be removed -
> though the API should still exist for special cases such as those
> plugins where absolute mode makes no sense. All other screens should be
> adapted to use absolute mode.

It was meant as a stop-gap measure, but some people seem to like it a
lot. I think we shouldn't totally drop it without serious reasons.

Frank

> What do others think?
>
> Rob.

-- 
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan

Received on 2009-11-08