GNOME Bugzilla – Bug 676758
Do not reorder VPN
Last modified: 2013-01-03 00:55:03 UTC
VPN listed in the menu are reorederd so that the connected one is at the top. This however is confusing: since just one VPN can be active at each time what happens to me very often is the following 1) I am connected to "Foo" VPN Connections: * Foo Bar 2) I want to switch to "Bar" VPN, which is the second in the list. 3) I disconnect from VPN, menu becomes VPN Connections: Bar Foo 4) I click on the second item in the menu, which was Bar when I started... 5) I am connected again to Foo :(
This is not a VPN specific issue, actually - it happens with all connection-based devices (so effectively everything but wireless). I'd like to hear designer input on this one - I believe it was part of the original design to highlight the current connection, and nm-applet always did it. (Btw, the actual rearrangement is partly a bug - connections are ordered by last-recently-used time, but that is often not updated by NetworkManager)
For wired it makes sense to reorder, since each connection is independent from the other. The problem with VPN is that at the moment you can just have one active, so switching VPN is a common task and that requires interacting with two items in sequence, so this is where the reordering becomes annoying. If we could have many VPN at once that would be solved :-) Another way to improve the situation is to make possible to switch from a VPN to another without having to disable first.
(In reply to comment #2) > Another way to improve the situation is to make possible to switch from a VPN > to another without having to disable first. This sounds the most reasonable solution. Why would you need to disconnect manually when the Shell can it it automatically? Is this really needed ATM? Advocating the devil: the fact that VPN entries swap their positions when you click on them can also be good for automatisms. It means the currently disabled VPN is always the second (when you have two of them), so you have to click on the same place everytime instead of wondering which VPN you want to enable.
(In reply to comment #3) > Advocating the devil: the fact that VPN entries swap their positions when you > click on them can also be good for automatisms. It means the currently disabled > VPN is always the second (when you have two of them), so you have to click on > the same place everytime instead of wondering which VPN you want to enable. That's not how humans work, according to a lot of usability research.
(In reply to comment #2) > Another way to improve the situation is to make possible to switch from a VPN > to another without having to disable first. And that's not possible? I'd say this is a bug in NetworkManager, but we can work around it in gnome-shell. Let me prepare something...
Created attachment 216061 [details] [review] NetworkManager: deactivate connection before activating a new one Apparently, NetworkManager doesn't allow to activate a new VPN over an existing one. To achieve the desired behavior of "switching" to a new connection, deactivate the existing one. The change is done at NMDevice level both for consistency and for code clarity.
At some point here though we're going to have the DEACTIVATING state implemented, which will call pre-down scripts that might take a bit of time to complete. So I'd rather make NM handle the deactivation, which we have to do already for devices, so we might as well do for VPN just to make things consistent. That said, even if this patch got committed, we'd still queue up the activation request internally in NM and start it after the deactivation was completed to ensure this patch worked as expected. So it's your call whether to commit this or not.
If you tell me NM will be fixed before 3.6, there is no need to push this to master. Otherwise, this should go in, and then we can fix it again when the DEACTIVATING state appears.
So, was this fixed in NM at the end? If so, please close this. Thanks!
This was fixed in gnome-shell when the VPN redesign landed. Closing!