After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 763443 - GtkSwitch: separate on/off state and switch position
GtkSwitch: separate on/off state and switch position
Status: RESOLVED INVALID
Product: gtk+
Classification: Platform
Component: Widget: Other
3.19.x
Other Linux
: Normal enhancement
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2016-03-10 10:05 UTC by Allan Day
Modified: 2018-02-13 16:38 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Allan Day 2016-03-10 10:05:33 UTC
In bug 725648, some separation was made between the position of a GtkSwitch and the state of whatever it controls. For example: a switch that controls Bluetooth can be off, but the switch can temporarily communicate that Bluetooth is actually still on.

It would be good to be able to use this to indicate when switches have been overridden. Examples of this in the controls center include the Location Services dialog and the search panel.

Currently, when a switch has been overridden, we keep it in its original position, but make it insensitive. This communicates what state the switch will return to when the override is removed.

The semantics don't quite right here, though: a switch that cannot be moved does not equate to a particular state of whatever is being controlled by the switch.

Extending the behaviour from bug 725648 could give us a better way to communicate these state changes. Switches would indicate the state of the function and the position of the switch separately, and we would no longer use insensitivity to communicate an override. That switches would remain interactive when an override is in place.
Comment 1 Allan Day 2016-03-10 10:34:04 UTC
Two potential risks with this change:

 1. There's a chance that colour change might not be enough to communicate the state change.
 2. We could end up with instances of "I'm pressing the switch but nothing's happening".

We could probably test for these, if they're a concern.
Comment 2 Matthias Clasen 2016-03-10 12:57:39 UTC
(In reply to Allan Day from comment #0)

>  That switches would remain
> interactive when an override is in place.

I understand that you still want to use the switch to communicate the effective state, but I'm not sure that this is quite right. An overridden switch is not going to have an effect, so inviting the user to interact with it is a bit misleading. Traditionally, we've made such overridden controls insensitive.
Comment 3 Matthias Clasen 2016-03-10 12:59:16 UTC
in any case, you can use the behavior from bug 725648 already to implement an interactive switch that lets you move the slider back and forth but never actually changes the state (which can be on or off).
Comment 4 Allan Day 2016-03-10 13:51:19 UTC
(In reply to Matthias Clasen from comment #2)
> (In reply to Allan Day from comment #0)
> 
> >  That switches would remain
> > interactive when an override is in place.
> 
> I understand that you still want to use the switch to communicate the
> effective state, but I'm not sure that this is quite right. An overridden
> switch is not going to have an effect,

It would have an effect when the override is removed. For example, you could decide whether Wi-Fi comes back on when airplane mode is disabled.

> so inviting the user to interact with
> it is a bit misleading. ...

Yes it could be misleading. It really depends on how people interpret the use of colour.
Comment 5 Matthias Clasen 2016-03-15 11:39:31 UTC
I think we need some idea how this would look and behave. Are there existing examples of such switch behavior ?
Comment 6 Matthias Clasen 2018-02-10 04:57:14 UTC
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
Comment 7 Bastien Nocera 2018-02-13 10:17:50 UTC
See also https://bugzilla.gnome.org/show_bug.cgi?id=644658
Comment 8 Allan Day 2018-02-13 16:38:42 UTC
(In reply to Matthias Clasen from comment #5)
> I think we need some idea how this would look and behave. Are there existing
> examples of such switch behavior ?

Sorry for the slow reply. I think we can probably leave this.