GNOME Bugzilla – Bug 694208
hide bluetooth menu when not in use
Last modified: 2014-03-04 15:37:07 UTC
I think we should do exactly what we did for the a11y menu. Hide the bluetooth menu when bluetooth is not in use. See bug 681528.
We already hide the bluetooth menu when not available, but differently from a11y, toggling bluetooth happens more often, if you use it. I mean, the theory behind bluetooth is that you keep it off until needed, then switch it on, do what you need, and then off again. And if you don't use it, chances are it's active anyway, because it is by default and it's not saved across reboots.
Having a menu up there all the time when it is off much of the time is not desirable. I would rather us be smart about when it is in use. Hide it until * Any bt devices are connected and in use * Any service requests discovery mode
(In reply to comment #2) > Having a menu up there all the time when it is off much of the time is not > desirable. I would rather us be smart about when it is in use. > > Hide it until > * Any bt devices are connected and in use > * Any service requests discovery mode Does not work in practice. Consider this case: I use BT to send files to my phone. So I open the menu, enable BT, connect the phone. And use the menu to send a file. When done I disable it again. * The device cannot connect because BT is off. * There is no service because the "service" is the menu itself.
So what you'll do in the future is enable BT from Settings. Or even better enable BT from wherever you are sending files from... Nautilus etc through Send To. Not a problem at all I think.
(In reply to comment #2) > * Any service requests discovery mode It's a killswitch. A phone that wants to connect to your computer from Bluetooth won't see it if it's off.
Nope, discovery mode is "Visibility".
Not quite sure what the story is with bluetooth and the new system menu. Reassigning so we can check this.
In the end, we implemented the behavior from the first iteration of the design: we only show the bluetooth section and indicator if there are connected devices (headphones or usb mice/keyboards). Note that bluetooth itself might be enabled (and consume power), but we don't show it anywhere. Also, if bluetooth is used for file transfer, it doesn't appear in the menu.
(In reply to comment #8) > In the end, we implemented the behavior from the first iteration of the design: > we only show the bluetooth section and indicator if there are connected devices > (headphones or usb mice/keyboards). > > Note that bluetooth itself might be enabled (and consume power), but we don't > show it anywhere. Also, if bluetooth is used for file transfer, it doesn't > appear in the menu. Do we show it when it is used for mobile broadband?
(In reply to comment #9) > (In reply to comment #8) > > Do we show it when it is used for mobile broadband? Yes, that's a different "Bluetooth", we treat the network side as a normal WWAN device (only showed if configured). The difference is in the icon (cellular signal vs bluetooth logo) and the menu contents (one launches bluetooth panel, the other network)
*** Bug 710225 has been marked as a duplicate of this bug. ***
(In reply to comment #7) > Not quite sure what the story is with bluetooth and the new system menu. > Reassigning so we can check this. Hi, my story is this: I usually turn blutetooth radio off while I have wifi on in order to get rid of unpleasant beeps from my laptop but I need bluetooth on from time to time. Current behaviour (as of 3.10) gets quite in a way when I need to enable bluetooth - instead of bluetooth icon/entry waiting for me at some harmless place to be turned on, I need to go to system status - settings - bluetooth - hit "On" to get the thing active and only then I can do useful stuff. Having at least an option in tweak tool (or even a dconf entry!) that could allow me to view instantly bluetooth rfkill status and change it would be really helpful.
Is this bug still relevant? There's bug 723848 which is more up-to-date than this one.
(In reply to comment #13) > Is this bug still relevant? There's bug 723848 which is more up-to-date than > this one. Good question. This really related to the standalone bluetooth menu, which no longer exists.