Hi,
I just went through a midnight read of this thread, might as well throw some
ideas relating to the several points which have (or have not) been made.
From a touchscreen perspective, you want to avoid spin buttons at large
cost if not all cost.
From my experience, in the context of a kiosk type machine (think touchscreen
jukebox or point of sales unit or such), first of all you want every
touchable area
to be *at least* as large as an index finger, even then some people with huge
fingers can and will be annoyed from using the interface.
If you have a 15" or 17" monitor & touchscreen to work with, as we did, then
you will probably permit yourself some spin buttons in the
operator/configuration
screens... you wont put very many in that screen... and the up and down arrows
will appear after the entry (not on top of each other but beside eachother, as
Emmanuele mentioned that takes too much height to be usable at all with touch).
However, even then with a 17" monitor we would never allow ourselves to place
these spin buttons in any "user" screens, the operator of the jukebox
has to spend
time configuring the thing, you dont want to annoy users with spin buttons.
On a tablet, if you really really cant avoid it, perhaps you can get away with
using a spin button. On a handset, I think you can just forget about it, or
limit yourself to having only one (or two ?) spin button visible at a
time (perhaps
inside a vertical scroll window, however sliders are usually better for this if
exact precision is not an issue).
Slider widgets need special care with touch as well, specifically you want
a huge knob, and you want the indication of "where you are" to be indicated
outside of the knob and not on top of the knob (perhaps the scale widget
is an index into the alphabet, or a numerical value, you want to see that
value "outside" the knob, not covered by your finger).
Secondly on slider widgets, you generally dont want this awkward "jumping" by
page size when the user touches the trough area.
The user's intention with a scale widget is to first "get the knob"
and then make
a modification to the scroll position (Up and Down buttons positioned above
and below the scale widget are helpful for fine grained modifications).
So the correct behaviour is to allow the finger to slide into the trough area
without modifying the scale value and allow the finger to "Enter" the knob
area... once the finger has entered the knob's area then the knob should
stick to the finger and move with it.
a.) It should not "jump" unexpectedly towards your finger
b.) It should not require that your finger cause the "button-press-event" to
occur on the knob, it should instead be tollerant and allow the finger
to slide into the knob area and control it.
The slider behaviour is also very critical when the slider is controlling
the master volume (of your home stereo system or whatever it is), of course
you dont want the volume to "jump" up just because you missed the knob
initially when trying to "catch" it).
On "bastardising" the toolkit to get touchscreen support in GTK+, I personally
never thought this was the point to touchscreen support in GTK+.
It will definitely be useful if for instance, GTK+ makes some things possible
on touchscreens which were not possible before, perhaps panning mode
in scrolled windows is a good example, at least some features in basic
widgets that you *need* in order to extend your UX to touchscreens.
One thing I'm most certainly convinced of is that applications (or their
user interfaces) will be written separately for touchscreen devices.
You wont be able to ship exactly the same code on a touchscreen
enabled device, set the gtk settings touchscreen mode = TRUE and
just hope for the best... that will never happen, or perhaps I'll just have
to see it to believe it.
So yes I think it's completely logical to build a widget kit on top of GTK+
which is particularly suitable for touchscreen environments, in any case
its what people will do (write custom widgets for touch in their own
applications).
I also believe that a GtkSwitch is programaticaly interchangable with a
GtkToggleButton, and it's a bit confusing too... when one changes a toggle
button to look "switchy" then one potentially needs to actually change code
(i.e. that vfunc which I was overriding in togglebutton no longer compiles
when I derive from switch ? ... I changed it for a switch and now
GTK_IS_TOGGLE_BUTTON() fails for a switch ? can I connect it
to that toggle action which I've been proxying my toggle buttons through
like before ?... definitely seems awkward).
Then again that's not really worth arguing, there wont be an api break till
GTK+4 anyway so...
Ok long night... food for though... lets sleep on it guys ;-)
Cheers,
-Tristan
On Sat, Aug 4, 2012 at 8:15 PM, Simon Feltman wrote:
> Toggle buttons and the switch widget both suffer usability problems for me.
> The visual look of a button represents an a
