Re: next steps for touch support in GTK+

Toggle buttons and the switch widget both suffer usability problems for me. The visual look of a button represents an action to be performed in my mind, perhaps why it was referred to it as a soft-action? So when a button is stateful it can create ambiguity depending on the text of the button. The old, "Does it perform the action shown on the label or does the label reflect the current state?" This causes dissonance in my mind which can hopefully be resolved by the widget having another visual indication of the state (the depressed look). A typical example of this failure is with Glades usage of toggle buttons on a selected widgets properties (don't mean to offend anyone here, just stating my experience!). This is further confused by the text changing when you press the button to Yes or No.

Moving on to the switch widget, I think it mostly suffers the same issues I've described. Does the text on the switch widget represent the current state or the action of setting the state to on or off. Again the visual indication barely saves me here (having it highlighted to blue). Given this, the visual indication aside from the text is what I use to determine the state of either a toggle or switch. This makes me think the text on the widget only confuses things and the widget could simply be a checkbox which would resolve all visual ambiguity. However, I do see value in what is described in the UX guidelines regarding the switch widget and associating it with things that take time (not just a simple checkbox state). The guidelines also don't describe explicit styling of the switch which is my problem with it. I think the visual ambiguity could easily be fixed by showing both available states, looks like it is already being discussed here:


On Sat, Aug 4, 2012 at 8:47 AM, David Nečas <yeti physics muni cz> wrote:
On Sat, Aug 04, 2012 at 03:39:05PM +0100, Emmanuele Bassi wrote:
> one implies a "soft" action (GtkToggleButton), whereas the other
> implies something similar of a hardware switch (GtkSwitch).

As every user knows, widgets relay wishes to magic pixies.  I wonder if
that is soft or hard action, maybe it depends on how hard you need to
beat the pixies to do what you want.

Do you actually expect different kinds of on/off controls to be mixed
wildly because each was selected based on how soft is the action it

> they both
> have their use cases which are not interchangeable:
> the page above should become part of the new Human Interface
> guidelines/design patterns. not every application should use switches,
> nor existing applications should be mindlessly migrated to moving from
> toggle and/or check buttons to switches.

All cases listed there as good use cases of GtkSwitch would be – for me
– improved by using a plain toggle button.

It would take less horizontal space, it would be less wordy, it would
not leave me wondering whether it shows ON when it is on or whether I
should move it to ON if I want it ON (yes, I still do not remember it),
it would not look trendy, and it would not have translation issues.  In
fact, even the ‘wrong’ checkbuttons would represent an improvement for

I would also say the widgets are completely interchangeable, but forced
to interpret the statement ‘their use cases are not interchangeable'
somehow I would have to conclude that GtkSwitch has no meaningful use
case at all.  Could the page be improved to include this?  In my opinion
it could lead to a considerable simplification of the guidelines.

> the short takeaway is that the switch should be used in specific
> cases, and that the way its been defined as a widget does not allow
> inheritance from GtkToggleButton or GtkButton (no label, no children,
> styling of trough and handle).

I am sorry but, again, this is just a recapitulation of the status quo.
Stating it a hundered times does not make problems vanish magically even
if you beat the pixies really hard with a switch.


gtk-devel-list mailing list
gtk-devel-list gnome org

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]