GNOME Bugzilla – Bug 646381
No indication of which wireless network is being connected to
Last modified: 2011-04-03 12:24:44 UTC
Created attachment 184822 [details] Screenshot of connecting state When I unsuspend, or if I (as a test) rmmod then modprobe my wirless driver I see in the menu only: Wireless Connecting... With nothing else about wireless. Then only when it's successfully connected, do the different wireless networks fill. This means that if anything goes wrong with the connection process (bug 646376 was what I was hitting earlier) the there is absolutely no clue to the user about what is happening, and they have no ability to select a different network. Jon thought there was something about this in the mockups, but I didn't see anything. The very simplest thing to do is simply to show the network list with the bullet next to the network being connected to. We could later get fancy and show a spinner next to the network being connected to or something, but since "Connecting..." is already displayed, it's reasonably obvious.
Created attachment 184873 [details] [review] NetworkMenu: keep the connection list visible when connecting... When a device is connecting, we can continue showing available connections and access points, as well as the active one with the dot. (Hiding was a remnant of when the device status was on a different menu item than the title)
Comment on attachment 184873 [details] [review] NetworkMenu: keep the connection list visible when connecting... > _shouldShowConnectionList: function() { > return (this.device.state == NetworkManager.DeviceState.DISCONNECTED || >- this.device.state == NetworkManager.DeviceState.ACTIVATED); >+ this.device.state == NetworkManager.DeviceState.ACTIVATED || >+ this.device.state == NetworkManager.DeviceState.PREPARE || >+ this.device.state == NetworkManager.DeviceState.CONFIG || >+ this.device.state == NetworkManager.DeviceState.IP_CONFIG); Hm... so that leaves UNKNOWN, UNMANAGED, UNAVAILABLE, NEED_AUTH, IP_CHECK, DEACTIVATING, and FAILED out. I think NEED_AUTH and IP_CHECK should be in. We might want to say: return (this.device.state >= NetworkManager.DeviceState.PREPARE && this.device.state < NetworkManager.DeviceState.DEACTIVATING) since the enum values look like they're designed to possibly have new states inserted in between them in the future. Let me ask dcbw about that.
From an IRC discussion with dcbw last night: <owen> dcbw: so that behavior is coming from <owen> _shouldShowConnectionList: function() { <owen> return (this.device.state == NetworkManager.DeviceState.DISCONNECTED || <owen> this.device.state == NetworkManager.DeviceState.ACTIVATED); <owen> }, <dcbw> owen: but it's odd that we wouldn't show the same list while connecting <dcbw> owen: with the dot like you suggest <owen> dcbw: yeah, I think it's probably an oversight <dcbw> owen: that should actually be this.device.state >= NM_DEVICE_STATE_DISCONNECTED && this.device.state <= NM_DEVICE_STATE_DISCONNECTING <owen> dcbw: I don't see a DISCONNECTING In the header file <owen> DEACTIVATING? <owen> But woudln't we want to show the list on FAILED as well? <owen> UNKNOWN/UNMANAGED/UNAVAILABLE seem like the only ones we wouldn't want a list <dcbw> yeah, DEACTIVATING <dcbw> sure <dcbw> that sounds fine <dcbw> if its >= DISCONNECTED, show the connections <owen> dcbw: that would apply to all device types? <dcbw> yes
Created attachment 184955 [details] [review] NetworkMenu: keep the connection list visible when connecting... When a device is connecting, we can continue showing available connections and access points, as well as the active one with the dot. (Hiding was a remnant of when the device status was on a different menu item than the title)
Review of attachment 184955 [details] [review]: Good with me pending release team approval.
Attachment 184955 [details] pushed as 38bcd52 - NetworkMenu: keep the connection list visible when connecting...