#394 closed Feature Wish (fixed)
OpenVPN GUI shouldn't (always) error when already running
Reported by: | tlhackque | Owned by: | Heiko Hund |
---|---|---|---|
Priority: | minor | Milestone: | |
Component: | Windows GUI | Version: | OpenVPN 2.3.2 (Community Ed) |
Severity: | Not set (select this one, unless your'e a OpenVPN developer) | Keywords: | |
Cc: |
Description
For windows, I have an installer that installs a config file and creates a desktop shortcut for "Connect to fooService". The target is "C:\Program Files\OpenVPN\bin\openvpn-gui --connect fooService.ovpn".
If openvpn-gui is not running, activating the shortcut does what's expected: starts the GUI and the GUI starts the tunnel.
If the user disconnects the tunnel, openvpn-gui does not exit. (OK)
Now, activating the shortcut results in "OpenVPN GUI is already running" as a pop-up error window.
This is not a good user experience. The user doesn't care that the GUI is running; the tunnel is not, and he wants it activated.
The second instance should simply pass the 'connect' command to the first instance and exit. Then the first instance can connect (or say 'already connected to ...').
I think this is a bug because the current behavior violates the principle of least surprise - though I suppose some might call it a feature request.
This has been experienced on XP SP3, though I would expect other versions to behave the same way.
Change History (6)
comment:1 Changed 9 years ago by
Owner: | set to Heiko Hund |
---|---|
Status: | new → assigned |
comment:2 Changed 7 years ago by
I have a branch that does this here github
If there is interest I can make a patch.
comment:3 Changed 7 years ago by
I agree that this behavior does not give a good user experience.
Looking at the age of the comments above, I thought there may have been some workaround but I can't find anything.
As it shouldn't impact existing use cases, is there any prospect of the fix being merged?
comment:4 Changed 7 years ago by
Its not really clear to me what behaviour would be preferred in various scenarios: E.g., no --connect option is used and an instance is already running but (i) no connections active (ii) many connections active. Or the new instance has a different --connect option than the already running instance.
Never got any feedback on the feature branch I referred to in the earlier comment either. Here is a link to the relevant commit in my private repo github
The approach in the above commit is to start auto-connect configs if any or show the already-running message as before.
comment:5 Changed 5 years ago by
Priority: | major → minor |
---|---|
Resolution: | → fixed |
Status: | assigned → closed |
Type: | Bug / Defect → Feature Wish |
This was addressed in PR 188 (in release 2.4.5, GUI version 11.10.0) that enhanced and improved handling of starting a second instance of the GUI.
comment:6 Changed 5 years ago by
Thank you very much for this, selvanair.
I have only tested it for 5 minutes but it appears to work very well.
Heiko, any idea how complicated this would be to teach to the Gui?