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.
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.
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?
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:
It does not conflict to the purpose of anon-connection-wizard
It can potentially benefit from the existing code in anon-connection-wizard
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.
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.
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).
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.
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.
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).
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:
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.
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.
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, import from anon_connection_wizard would look into the script with the same name instead of the package folder.
add restart-tor-gui
The 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.