I am not sure this is top priority. However a GUI tool to replace the full screen konsole when restarting Tor might be nice.
The script uses the thread from anon-connection-wizard to show the bootstrap progress. It closes itself with some delay when 100% is reached. Some error handing is added.
The name of the package is open to discussion, as well as the location of the script.
Awesome. Nice to see you back 
Can this be part of anon-connection-wizard? Shall we turn anon-connection-wizard into a full Tor controller? @iry
troubadour:
@iry
Do you mind if I start on this one ?
You are definitely welcome to work it!
I am thinking that if it is a good idea to add the reload and restart
Tor features in anon-connection-wizard. My concern is that maybe too
many features and options for users which may lead to poor user
experience. Although we may hide those two options under an "advanced"
button, still this may be confused. Therefore, having those two features
in another GUI seems to be a better idea. What do you think?!
Also I am thinking maybe I can make the code of controlling to Tor) as a
more Independent module so that you can use it in the new GUI
application without having to implement and maintain any new code. What
do you think?
This seems to be really easy to implement in anon-connection-wizard (serveral lines of code) and I do not see any conflict to the purpose of the anon-connection-wizard.
My only concern is
What do you think?
Hi @troubadour !
Maybe it is a good idea not to start coding before we figure out if these features are better to be part of the anon-connection-wizard or a standalone application?
No changes at that place were suggested. Agreed, it wouldn’t fit there.
Looks standalone already.
https://github.com/troubadoour/restart-tor-gui/blob/master/usr/lib/restart-tor-gui/restart_tor_gui.py seems pretty independent. No actual changes to the current anon-connection-wizard window. It’s like a separate gui tool to be added to the anon-connection-wizard package.
The question is, if using separate tools, is the anon-connection-wizard package (not the current anon-connection-wizard window) a good place to become a full Tor controller? Should the Tor restart gui be a separate source package?
Tor restart gui wouldn’t justify a separate package. It’s more like we’re starting to invent a Tor controller. (Something similar to vidalia / tor-arn (nyx).) That’s what I meant with should anon-connection-wizard morph into a full Tor controller?
I believe having restart GUI in the same package with anon-connection-wizard is a good idea because:
I see. Since vidalia died and nyx is more used in CLI cases, I do not mind making anon-connection-wizard into a Tor controller. However, do we need to intend to make it a full Tor controller? In another word, what else features should be included into anon-connection-wizard if we really think making it a Tor controller is a good idea?
If we integrate tor-restart-gui in the package without any modification of anon-connection-wizard code, I guess it would be a matter of adding a .desktop file in /usr/share/applications so that it can be run from the start menu
The shared code between anon-connection-wizard and tor-restart-gui is the TorBootstrap class. Why not make a separate module for it. Furthermore, it would put stem in its own module.
I will look into that! BTW, do you know if having two .desktop in one package will be possible/okay, @Patrick ?
Sounds great to me!
iry:
I will look into that! BTW, do you know if having two .desktop in one package will be possible/okay, @Patrick ?
Very much possible. anon-gw-anonymizer-config ships (related ones only):
/usr/share/applications/gateway-restarttor.desktop
/usr/share/applications/gateway-reloadtor.desktop
/usr/share/applications/gateway-stoptor.desktop
The ones replaced should be deleted there.
Sounds great to me!
Great!
iry:
However, do we need to intend to make it a full Tor controller?
No, I doubt any third party could reasonably ask for our intent. We can
do what we want. It’s just since you’re the primary maintainer of it
now, it should be up to you to not morph it into something you cannot
maintain.
In another word, what else features should be included into anon-connection-wizard if we really think making it a Tor controller is a good idea?
Good question. Something like Vidalia. But that is rather long term and
low priority. And with better usability. Something where you can monitor
Tor, configure Tor. Not easy since more options are not necessarily for
the benefit for the user.
Related:
Whonix specific or Whonix unspecific?
And how would we integrate it with sdwdate-gui so that there is only one
systray (Qubes wants not too many systray’s by Whonix, so just one, but
perhaps could be discussed, however didn’t since not an easy task not
priority).
Specifically hard in Qubes:
I have started on this one. I hope this is OK.
anon-connection-wizard works with TorBootstrap thread in its own module. Still having an issue with tor-restart-gui (or should it be tor-restart?)
Merged your changes in anon-connection-wizard
restar-tor-gui (not tor-restart-gui) is working too.
Integration of restart-tor-gui in anon-connection-wizard is done.
It was split in three commits.
new module tor_bootstrap
change python package name anon_connection_wizard to anonconnectionwizard
This is required because after adding the main package restar-tor-gui, from anon_connection_wizard import would look into the script with the same name instead of the package folder.
add restart-tor-gui
The fourth commit is the correction of a mistake done during splitting of the work.
Patrick Schleizer:
iry:
However, do we need to intend to make it a full Tor controller?
No, I doubt any third party could reasonably ask for our intent. We can
do what we want. It’s just since you’re the primary maintainer of it
now, it should be up to you to not morph it into something you cannot
maintain.
Great! I have no intention to make it a full Tor controller since it
will just be an ugly/inflexible GUI wrapper of python stem then.
Good question. Something like Vidalia. But that is rather long term and
low priority. And with better usability. Something where you can monitor
Tor, configure Tor. Not easy since more options are not necessarily for
the benefit for the user.Related:
- Whonix Tor Controller - âš“ T90 Whonix Tor Controller
- Whonix Control Panel - âš“ T89 Whonix Control Panel
Whonix specific or Whonix unspecific?
And how would we integrate it with sdwdate-gui so that there is only one
systray (Qubes wants not too many systray’s by Whonix, so just one, but
perhaps could be discussed, however didn’t since not an easy task not
priority).sdwdate-gui: Secure Distributed Web Date Graphical User Interface
Specifically hard in Qubes:
âš“ T534 make sdwdate-gui Qubes friendly (sdwdate-gui-qubes)
Thank you for your detailed answer, Patrick! I will look into that and
think about it. 
iry:
Patrick Schleizer:
iry:
However, do we need to intend to make it a full Tor controller?
No, I doubt any third party could reasonably ask for our intent. We can
do what we want. It’s just since you’re the primary maintainer of it
now, it should be up to you to not morph it into something you cannot
maintain.Great! I have no intention to make it a full Tor controller since it
will just be an ugly/inflexible GUI wrapper of python stem then.
That’s not what I meant with “full Tor controller”. Vidalia was a “full
Tor controller”. It does not mean to have each and every function of
python-stem available in a gui. It’s not a python-stem gui. Perhaps I
should have defined “full Tor controller”.
Simple way to interact with Tor:
“full Tor controller”:
We don’t have to make any changes to the actual anon-connection-wizard
as currently is. Any Vidalia replacement would be a separate program.
That program might run/integrate anon-connection-wizard, but that’s
about it. And share common code where useful. Like restart-tor-gui is
now a separate program.
Patrick Schleizer:
That’s not what I meant with “full Tor controller”. Vidalia was a “full
Tor controller”. It does not mean to have each and every function of
python-stem available in a gui. It’s not a python-stem gui. Perhaps I
should have defined “full Tor controller”.Simple way to interact with Tor:
- just create Tor config and restart
- send NEWNYM
- that’s what Tor Browser originally did (not sure it became a full Tor
controller yet)“full Tor controller”:
- subscribe to Tor setevent events
- keep watching what Tor is reporting as status, forward that status to
the user- something like tor-arm (nyx) / Vidalia
We don’t have to make any changes to the actual anon-connection-wizard
as currently is. Any Vidalia replacement would be a separate program.
That program might run/integrate anon-connection-wizard, but that’s
about it. And share common code where useful. Like restart-tor-gui is
now a separate program.
I see! That seems to be something really interesting! I will take
looking into the reason why Vidalia failed and learning from it as my
first step.
troubadour:
Integration of
restart-tor-guiinanon-connection-wizardis done.It was split in three commits.
new module
tor_bootstrapchange python package name
anon_connection_wizardtoanonconnectionwizard
This is required because after adding the main package restar-tor-gui,import from anon_connection_wizardwould look into the script with the same name instead of the package folder.add
restart-tor-guiThe last commit is the correction of a mistake done during splitting of the work.
Could you please create a Whonix 15 ticket for that? This would be
probably mergable (easy and) early during Whonix 15 development.
What about merging restart-tor-gui into tor-control-gui?
Please don’t rename desktop files /usr/share/applications/gateway-restarttor-gui.desktop so Qubes white listed appmenu entries keep working.