GNOME Bugzilla – Bug 709128
select network option is lame when wifi is off
Last modified: 2014-02-06 18:45:33 UTC
I had a problem earlier today where the network said it was connecting but wasn't working. I turned wifi off using the menu and then wanted to select another wifi access point. I was expecting to turn wifi back on first but noticed that it allowed me to select a network from them menu right away. I selected this item but then the dialog that came up said something like No Networks. There are a few problems with this. * It wasn't true that there were no networks. The wifi was just off. * We should either disable or remove the select network item in the menu or make it work - we could have an option to turn it back on from the dialog directly after identifying that it is off - or just make it turn on automatically when I ask for a network
(In reply to comment #0) ... > - we could have an option to turn it back on from the dialog directly after > identifying that it is off > - or just make it turn on automatically when I ask for a network ... I wasn't sure about the choice between these two options, either. Right now I'm leaning slightly towards the latter: we have to assume that wi-fi was turned off for a reason (probably power saving); providing the option to turn it on means that we acknowledge the previous action and allows the user to change their mind. The dialog also needs to indicate airplane mode and hardware disabled states. I've elaborated the wireframes with details for each of these: https://raw.github.com/gnome-design-team/gnome-mockups/master/shell/system-menu/wi-fi-dialog.png
(In reply to comment #1) > (In reply to comment #0) > ... > > https://raw.github.com/gnome-design-team/gnome-mockups/master/shell/system-menu/wi-fi-dialog.png Uhm... what's the difference between airplane mode and wifi off? Currently, if you turn off wifi you get the airplane mode submenu, unless there is also a bluetooh or wwan rfkill installed. On a related note, should we have a Scan button in that dialog, or force a new scan when the dialog is opened?
*** Bug 709645 has been marked as a duplicate of this bug. ***
(In reply to comment #2) > > https://raw.github.com/gnome-design-team/gnome-mockups/master/shell/system-menu/wi-fi-dialog.png > > Uhm... what's the difference between airplane mode and wifi off? > Currently, if you turn off wifi you get the airplane mode submenu, unless there > is also a bluetooh or wwan rfkill installed. My understanding is that airplane mode disables other things like bluetooth and mobile broadband. If those things were on when airplane mode was switched on, I would expect them to come back on again when it is turned off. > On a related note, should we have a Scan button in that dialog, or force a new > scan when the dialog is opened? Force a new scan when it's opened, I'd say.
(In reply to comment #4) > My understanding is that airplane mode disables other things like bluetooth and > mobile broadband. If those things were on when airplane mode was switched on, I > would expect them to come back on again when it is turned off. Yeah, exactly. For example, if I'm connected to a wifi network FOO with autoconnect off, and I enable and disable airplane mode, I expect OS to re-connect me again to the previous network (even though it's configured to not autoconnect). Because airplane mode is "temporarily shut down everything radio related (wifi, bluetooth, etc), and then restore the previous state", similar to system suspend. But hardware rfkill is something different, if I toggle it on and off, I don't expect to be automatically connected to the previous network (when it's not my preferred network with autoconnect on). (In reply to comment #3) > *** Bug 709645 has been marked as a duplicate of this bug. *** I have a short video in there. I recommended to add "Turn On" button to the wifi selection dialog. But William's idea to turn it on automatically is even better, I think. If I want to select a network, it makes little sense to have the device disabled. I don't see a use case when I'd want to see that dialog without having wifi on.
*** Bug 708339 has been marked as a duplicate of this bug. ***
*** Bug 711132 has been marked as a duplicate of this bug. ***
Created attachment 267451 [details] [review] Revert "network: Use NMDevice.get_available_connections(); for NMWirelessDialog" This reverts commit a36bfced473d48ffe70150ad5537bb82b1ead8e8. get_available_connections() returns the connections that are available right now, ie, with the currently visible APs, but that might change while the dialog is open, so we can't use it.
Created attachment 267452 [details] [review] NMWirelessDialog: show an informative message when airplane mode is on Rather than just showing "No networks", inform the user if airplane mode is on or if wifi is off, and allow the user to change that from the dialog (if possible).
Review of attachment 267451 [details] [review]: I don't see how the old code helps with that, though. If you want the dialog contents to dynamically update, connect to "notify::available-connections"
(In reply to comment #10) > Review of attachment 267451 [details] [review]: > > I don't see how the old code helps with that, though. If you want the dialog > contents to dynamically update, connect to "notify::available-connections" It helps because the old list only changed when a new connection was added to the settings, the new one depends on APs too.
(In reply to comment #11) > It helps because the old list only changed when a new connection was added to > the settings Not as far as I can see. It was statically from list_connections(); when the dialog is opened. What's the use case you imagine when wanting to connect to an AP considered unavailable?
(In reply to comment #12) > (In reply to comment #11) > > It helps because the old list only changed when a new connection was added to > > the settings > > Not as far as I can see. It was statically from list_connections(); when the > dialog is opened. What's the use case you imagine when wanting to connect to an > AP considered unavailable? Sorry, I wasn't clear. What I meant is that, we were supposed to change that list only when the connections where changed in the settings, and not also as the AP appeared. Because the latter event is rarer, we kept the list static and lived with it - it was a minor bug. On the other hand, keeping the list static to AP changes is a problem, especially when you mix in airplane mode. Specifically, what I got here was that after leaving airplane mode with the dialog the _connections array was empty, which is clearly wrong. (Actually, it was null, not empty, which caused a crash. So whatever we do, at least "|| []" is needed there)
Review of attachment 267451 [details] [review]: OK then. I'm not the happiest, but I'll live with it.
Review of attachment 267452 [details] [review]: ::: js/ui/status/network.js @@ +629,3 @@ this._device = device; + this._rfkill = Main.panel.statusArea.aggregateMenu.rfkill; Ugh. This is really meant to be private and not accessed like this. I'd rather see a Rfkill.getRfkillManager(); type thing @@ +659,3 @@ + /* If there are no visible access points, request a scan */ + this._device.request_scan_simple(null); + } Can you please split out these separate fixes? @@ +780,3 @@ + this._noNetworksBox.add_actor(new St.Label({ style_class: 'no-networks-label', + text: _("No Networks") })); + this._stack.add_child(this._noNetworksBox); Can you split out these noNetworks fixes separately, along with the spinner add? @@ +1016,2 @@ if (network.accessPoints.length == 0) { + network.item.actor.destroy(); This one too.
Created attachment 267579 [details] [review] rfkill: split out the dbus handling parts from the indicator status.network wants to watch for airplane mode too, we can share the code with a manager singleton.
Created attachment 267580 [details] [review] NMWirelessDialog: fix removing access points We must destroy the actor, not the item, because the latter doesn't have a destroy() method.
Created attachment 267581 [details] [review] NMWirelessDialog: request a scan when there are no visible access points Ideally, we should keep scanning while the dialog is open, and stop (or reduce the frequency) when it's closed. Forcing a new scan when the dialog is opened empty is a close approximation and increases the probability that the user will find the AP he needs.
Created attachment 267582 [details] [review] NMWirelessDialog: show an informative message when airplane mode is on Rather than just showing "No networks", inform the user if airplane mode is on or if wifi is off, and allow the user to change that from the dialog (if possible).
This is as split as I can get. Anything else would be a rebase nightmare. Btw, we need a larger spinner, because the current one only works at 24x24 (which is really small). Or we need a better spinner implementation (one that rotates it programmatically instead of using a sprite)
Review of attachment 267579 [details] [review]: Looks good, minor nit. ::: js/ui/status/rfkill.js @@ +94,3 @@ + let hwAirplaneMode = this._manager.hwAirplaneMode; + let changed = (airplaneMode != this._indicator.visible) || + (hwAirplaneMode != this._offItem.actor.visible); Unused?
Review of attachment 267580 [details] [review]: Oops, yes.
Review of attachment 267581 [details] [review]: OK.
Review of attachment 267582 [details] [review]: Again, can't you split out the addition of the spinner and the other new elements to the no networks view? ::: js/ui/status/network.js @@ +749,3 @@ }, _updateVisibility: function() { You should rename this if it does more than update the visibility.
Renamed updateVisibility to syncView, for lack of a better name. It has sync in it, so you should like it ;) Didn't split them because it would have a lot of git pain, for very little gain. Attachment 267579 [details] pushed as 2fe760c - rfkill: split out the dbus handling parts from the indicator Attachment 267580 [details] pushed as 1272eaf - NMWirelessDialog: fix removing access points Attachment 267581 [details] pushed as 7f1e420 - NMWirelessDialog: request a scan when there are no visible access points Attachment 267582 [details] pushed as ea1f5a8 - NMWirelessDialog: show an informative message when airplane mode is on
Attachment 267451 [details] pushed as a4adcba - Revert "network: Use NMDevice.get_available_connections(); for NMWirelessDialog"