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 634328 - Bluetooth menu: lightswitch labels don't make sense
Bluetooth menu: lightswitch labels don't make sense
Status: RESOLVED DUPLICATE of bug 618312
Product: gnome-shell
Classification: Core
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
Depends on: 618312
Blocks:
 
 
Reported: 2010-11-08 15:42 UTC by Allan Day
Modified: 2010-11-12 17:42 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Allan Day 2010-11-08 15:42:45 UTC
The GS bluetooth menu [1] has three entries which contain a lightswitch. They read:

Active     [ On | Off ]
Visible    [ On | Off ]
Connected  [ On | Off ]

Each of the labels describes a state in the present tense. It doesn't make sense to be able to switch such a state off and on again. Also, it's confusing to have a dynamic widget label. Something like this would make sense:

Bluetooth   [ On | Off ]
Visibility  [ On | Off ]
Connection  [ On | Off ]

You lose the status info, though there might be other ways to display that (an icon, maybe?)

[1] http://www.hadess.net/2010/11/bluetooth-in-gnome-shell.html
Comment 1 Bastien Nocera 2010-11-08 15:45:30 UTC
gnome-bluetooth currently has separate labels for status and the actual action of toggling the state. We should probably go back to that in the shell.
Comment 2 William Jon McCann 2010-11-08 15:53:14 UTC
Yeah Bluetooth and Visibility sound much better. Connection sounds a bit better too or another option is to use an explicit Disconnect item there.

Also the menu should use "Settings" not "preferences".
Comment 3 Giovanni Campagna 2010-11-08 16:20:54 UTC
(In reply to comment #0)
> The GS bluetooth menu [1] has three entries which contain a lightswitch. They
> read:
> 
> Active     [ On | Off ]
> Visible    [ On | Off ]
> Connected  [ On | Off ]
> 
> Each of the labels describes a state in the present tense. It doesn't make
> sense to be able to switch such a state off and on again. Also, it's confusing
> to have a dynamic widget label. Something like this would make sense:

But it is not dynamic. It is Active [Off], when off, and Active [On] when on.
Basically, I'm treating toggle switches as checkboxes.

I'm okay with changing the labels (it is a matter of translation anyway), less so with adding a menu item for state / action. Inactive items don't look good, and we would need some sort of grouping to link Activate with Active and Make visible with Visible.

(I would have been happier if this discussion happened on bug 618312, one less bug to follow)
Comment 4 Allan Day 2010-11-09 09:09:24 UTC
(In reply to comment #3)

> But it is not dynamic. It is Active [Off], when off, and Active [On] when on.

My mistake. The bug still stands, though.

> Basically, I'm treating toggle switches as checkboxes.

Yeah, I think the logic is a bit different. Switch labels should refer to services or functions, not states, I would say.
 
> I'm okay with changing the labels (it is a matter of translation anyway), 

Great!

> less
> so with adding a menu item for state / action. Inactive items don't look good,
> and we would need some sort of grouping to link Activate with Active and Make
> visible with Visible.

I hadn't meant to suggest that extra menu items should be introduced. The string change for the first two entries should be enough. As for 'Connection', I agree with Jon - replacing that item with a Disconnect action could make sense (the switch would need to be removed from there, in that case).

> (I would have been happier if this discussion happened on bug 618312, one less
> bug to follow)

I'll update 618312 later today.
Comment 5 Dan Winship 2010-11-12 17:42:58 UTC
yes, since this code hasn't even been committed yet, we don't need a separate bug about redesigning it

*** This bug has been marked as a duplicate of bug 618312 ***