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
> - 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).
I think that the grid mode is silently turned on in some places is a
real problem. There really ought to be an indication. I think a
graphical grid that is always drawn when the grid mode is on would be
really useful and handy. It could be also only drawn when the
touchscreen has been pressed and for 5s or so.
The default WPS should be convertible rather easily, it can even be done
on a per-target basis (the clip has its own WPS too).
> 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"? 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.
Well, that happens if drawing and button handling is mixed together too
much. Really any screen should have its drawing routines and
action/button handling separate, then what you describe won't be much of
a problem. And I think that viewports allow to implement this separation
in a rather convenient manner.
The color picker screen is a (semi-)good example of this separation.
Touchscreen handling is completely separate. The only problem it has is
that the touchscreen handler guesses the viewports instead of
retrieving them from the drawer (but that is relatively easy to fix -
either by having static viewport arrays or letting the drawer call the
I have not looked at the EQ screen code so I apologize if I told
something wrong now.
> 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.
I, for myself, find the grid mode generally crippled by design. But
there are many places in rockbox where it a) is a good choice or b)
converting to touch mode is a lengthy job/pain. But I wouldn't mind to
much if it stays, it should just be reduced to be used only in some
Received on 2009-11-08