Re: next steps for touch support in GTK+

[Emmanuele Bassi <ebassi gmail com>]

hi;

On 4 August 2012 14:14, Paul Davis <paul linuxaudiosystems com> wrote:

> On Sat, Aug 4, 2012 at 3:50 AM, Emmanuele Bassi <ebassi gmail com> wrote:
>
>  [ ... ]
>
> and yet another case of "i'm so nervous and irritated by criticism of our
> design decisions that i'll resort to calling people stupid" ...

design has nothing to do with it, sorry to disappoint the conspiracy theorists.

just another case of "somebody is wrong on the Internet" that I should
know better not to reply to.

>> and yet another case of "I don't know that, so I'll make stuff up".
>>
>> On 2 August 2012 14:11, Paul Davis <paul linuxaudiosystems com> wrote:
>>
>> >> === 3. SpinButton ===

>> >> Another option is introducing a complete new widget targeted at touch
>> >> usage (similar to the one in iOS Garageband) [4] which Carlos
>> >> implemented
>> >> already [5]. The issue is here the height, which at least in a Sugar
>> >> toolbar
>> >> could be not as ideal and introducing a new widget.
>> >
>> >
>> > votes++. The spin button in gtk3 has already been bastardized from its
>> > original mouse/kbd/space-friendly form.
>>
>> yes, because 6x6 pixel targets are *sooooo* mouse friendly.
>
>
> My remark consisted of a triple: "mouse/kbd/space-friendly". What that
> meant, if you want it fully decomposed was:
>
>    "its original form that was very favorable in terms of the space it used
> and the amount of mouse/pointer motion required to move the value in two
> different directions, and was clearly oriented towards being controlled by
> either a mouse, whose pointer focus is small enough that the design worked,
> or a keyboard (where the on-screen display size is irrelevant). the one
> thing that it was not absolutely friendly towards is touch control, for
> obvious reasons"

just FYI, if you have a point to make, it helps actually making it -
not writing down half-formed sentences and expecting people to deduce
what you meant.

"the previous design worked": here is where you and I completely disagree.

moving the controls on the horizontal axis from the vertical does not
impinge in the ability to change the values; it does allow increasing
the target area to the height of the entry, instead of splitting it in
half. it makes the target immediately recognisable and improves the
chances of hitting the desired target. it also adds the ability to do
things like a proper focus ring without cramming it in with the icon.

if, with the older widget layout, you could hit either the up or down
arrows at first sight, just by moving the pointer without fine
control, then congrats: you either have a precise control on the
pointer, or you have an accurate pointer device. neither of those two
conditions are a given - and, actually, the latter is becoming the
norm given the incredibly crappy trackpads that are now commonplace
everywhere that does not have an Apple logo.

if keyboard navigation is broken, that would warrant a bug, as it
would be a pretty serious regression.

touch had a factor in changing the layout of the SpinButton, but less
than the considerations on accessibility and input devices that I
outlined above; gtk+, unlike some applications, has the challenge of
working on different form factors as well as different input methods,
so we need to be touch-friendly - even if we're not touch-driven (and
we most definitely are not).

adding a TouchSpinButton would still be recommended, and probably will
happen at some point; but it would also very likely have a *very*
different layout than the current SpinButton anyway.

ciao,
 Emmanuele.

-- 
W: http://www.emmanuelebassi.name
B: http://blogs.gnome.org/ebassi/