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: Touchscreen Interface

Re: Touchscreen Interface

From: Rob Purchase <rob.purchase_at_googlemail.com>
Date: Sun, 08 Nov 2009 19:05:37 +0000

On 08/11/2009 17:37, Thomas Martitz wrote:
> 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.

I was thinking more like adding a splash or something to those 'forced'
changes, just so the user is always alerted when the control scheme
changes. Although that could be annoying - maybe a big, obvious status
bar icon instead?

I'm not sure how useful displaying a grid would be in reality
(especially since no-one's needed one so far), and it could be a pain to
implement everywhere.

> 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).

Yes, although using target-specific WPSs to enable touchscreen features
will probably lead to some nasty duplication, eg there's already a
touch-enabled 320x240 CabbieV2 for the m:robe500.

Might it be better to add something to wpsbuild.pl for touchscreens, so
that if the target defines HAVE_TOUCHSCREEN, it looks for
"<name>.<size>.touch.wps" or "<name>.<size>.<device>.touch.wps" in
preference to the generic versions?

There is also the problem that the current 320x240 Cabbie font is a
little too small to use comfortably in absolute touch mode - and
changing this will have a knock-on effect on the whole layout.

> 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
> button handler).

That's fine so long as what you draw on the screen, and how it works
functionally, is the same for button control and touch control. If you
want to do something different for touch screens (eg. using on screen
buttons) you need to use a different approach - see the EQ menu FS task.

Frank's option d) might be the best option for cases like this, albeit
slightly bloated (although having said that, touchscreen targets seem
unlikely to be short of memory).

Rob.
Received on 2009-11-08

Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy