Closed GoogleCodeExporter closed 9 years ago
Welcome back!
A menu command that closes all open connections seems like a good idea. I'm
leaning toward a separate menu command, though, at the bottom of the list of
connections, instead of replacing the status header. I think that makes the
header too complicated looking/sounding. But I'll think about it.
Some new features of Tunnelblick would let you create such a menu command
yourself, though -- by using a combination of Tunnelblick's add-a-menu-command
feature and AppleScript capability. It would be messy, though, and not needed
if I put it in the program directly. For info on adding menu commands to
Tunnelblick, see
https://code.google.com/p/tunnelblick/wiki/wCusDeployed#Additional_Menu_Commands
_and_Programs
Another option would be to just make a short AppleScript that you put somewhere
convenient (like the Desktop or Dock) that would close all the connections.
Tunnelblick has two commands that would be of interest: 'disconnect all' and
'disconnect all except when computer starts'. For info on Tunnelblick's
AppleScript capabilities, see
https://code.google.com/p/tunnelblick/wiki/wAppleScriptSupport
One thought that comes to me is that the "connected" indicator should be
"propagated" out to the visible menu even if a configuration is buried deep in
a subfolder. I want to think about that, too.
Finally, I just realized that the "doNotShowConnectionSubmenus" preference was
not documented. I have now documented it in
https://code.google.com/p/tunnelblick/wiki/wPrefs. If you set it true, it shows
each connection directly in the menu, even if it is buried in a subfolder,
instead of showing a menu hierarchy. Give it a look.
Original comment by jkbull...@gmail.com
on 28 Apr 2011 at 11:08
A separate menu item is fine by me. That gives you the option to simplify the
status header too, if you choose to. Eg. move the About... item out of
Options and make it "About Tunnelblick 3.1.7..."
For the new menu item, you could have it vary between not present (for no
connections), "Disconnect Active Tunnel" (for 1 connection), "Disconnect Both
Tunnels" (for 2), and "Disconnect All 3 Tunnels" (for 3 or more). Consider
also that many people only have one config file, and it's not in a submenu, so
it wouldn't make sense at all for them; the disconnect option is already in the
main menu. You might consider changing the "Details..." item to "View
Details..." too, just to allow a 'D' keystroke to discern between that and a
line starting with Disconnect.
While you're working on this, I found something else while I was playing around
yesterday. I opened three simultaneous tunnels, and watched the status header
as I started disconnecting them one by one. It stayed at "3 connections
active" until they were all gone. I didn't open a separate issue for this, as
it will most likely be rendered moot if you implement this enhancement.
Not sure how you would "propagate" a disconnect out of a submenu. Have you
come up with an idea of how this would work?
I'll check out the AppleScript/add-a-menu-command features. I wasn't aware of
them; sounds like you've been busy!
As always, one of the best FOSS projects around and the only OVPN GUI I would
consider for OS X!
Original comment by petiep...@gmail.com
on 29 Apr 2011 at 8:46
Thanks for your comments. I'll be thinking about this...
Re: showing "3 connections active" even as they were disconnecting one by one:
Do you mean:
(A) You started disconnecting all three, and then clicked the Tunnelblick icon
to show the status line, and waited, watching the status line not change while
the disconnections were completed?
or
(B) you started the disconnects, then you clicked the icon and it still said 3
active, then you clicked it again or clicked somewhere else (so the menu
disappeared) and then another disconnection competed, you clicked the icon a
third time, and with all three connections disconnected, the status line still
said there were three active connections?
I withdraw my "propagation" comment -- it wouldn't help much. I had been
thinking you could click on it to disconnect, but since there could be multiple
connections in the hierarchy that the menu item represents, it would have to be
a "disconnect everything in this hierarchy" click, and that's too complicated,
both to do and to explain. So I think a "Disconnect all" menu item is better.
So here's a proposal:
Add a new menu item, at the bottom of the list of connections (i.e., above
"Details..."). It would say "Disconnect 0 connections" (dimmed/disabled), or
"Disconnect 1 connection", or "Disconnect all N connections", depending on the
circumstances.
By default, the menu item will appear only when there is more than one
connection. A preference would force it be displayed all the time, even if
there were no connections.
So most people (the 60% who only have one configuration, and those who only use
one connection at a time) won't be annoyed by the useless-to-them, potentially
distracting new item. Users who occasionally have more than one connection will
have the ability to easily disconnect all of them. Users like you, who
frequently have more than one connection, could set the preference so that the
menu is stable (so "Details..." is in the same place all the time, allowing
muscle memory to get you there).
And "View Details..." seems like a good idea, too. Thanks.
Original comment by jkbull...@gmail.com
on 30 Apr 2011 at 11:45
I like your proposal. I wouldn't change a thing. Thanks!
Re: "3 connections active," I just did it again, running ps -ef between
disconnects to ensure that the openvpn process count went down. I would try to
click fast and pull down the menu a few times while changes were in progress,
clicking outside to dismiss before pulling down again. That's how I caught a
3->1->2 change when I reconnected tun1. I'll open a separate issue report on
this, as this is getting off the main thrust of this thread.
Original comment by petiep...@gmail.com
on 30 Apr 2011 at 6:10
I have committed (r1468) something closer to your original idea, to make the
status line also serve as a "disconnect all" line. r1468 also fixes the bug you
mentioned in comment 4.
Original comment by jkbull...@gmail.com
on 2 May 2011 at 1:00
Original comment by jkbull...@gmail.com
on 2 May 2011 at 1:00
Original issue reported on code.google.com by
petiep...@gmail.com
on 27 Apr 2011 at 8:21