Thus spake Leo Unglaub (leo@xxxxxxxxxxxxxxx): > Hey guys, > thanks for all the feedback. I am happy there is an interest from your > part in this project. > > I am trying to answer to all of your questions below. > > > (since Vidalia and the TBB are two different application windows) > > > > Is that an issue you're trying to solve in your rewrite? > > I didn't address this problem specific, because my UI is complete > different than the current one. So i hope this confusion will be fixed > automatically. This is actually a pretty deep problem with many pieces. It might not be fixed automatically so long as the OS considers the Tor Controller a separate app. Right now, users are currently confused in multiple ways by Vidalia being a separate app from the browser: 1. The appearance of the Vidalia window before the browser window causes many users believe that Vidalia is somehow routing *all* traffic through Tor, and that it is safe to use *any* browser once the Vidalia status bar has completed (and sometimes even before). 2. Another common source of confusion is the separate Vidalia Dock icon on Mac, Windows 7+, and Gnome/Unity desktops. This causes all manner of sub-problems: 2a). People sometimes dock the wrong app icon and later try to launch the Tor Browser directly without Vidalia. 2b). People get confused over which app (Vidalia or Tor Browser) they actually need to quit when they're done using the software. 2c). To make matters worse: For some reason, technically sophisticated users won the argument that TBB's Vidalia+Tor should remain open after the browser was closed (so they could manually configure other app SOCKS settings to point at Tor's SOCKS port, and manually re-launch the browser piece from the command line). This choice was made to the detriment and confusion of novice users, who often end up launching several copies of Tor over time, or simply giving up on TBB altogether when it fails to re-launch with Vidalia open, depending on their OS's dock behavior. Not to mention Vidalia+Qt adds 11M to our *compressed* bundle size (60M+ on disk), and also doesn't appear to have a dedicated maintainer. So the situation is pretty dire, in my opinion. Our plan over the next few months is to create a super-simplified Tor Controller as a Firefox extension for TBB that can configure proxies/bridges/pluggable transports (but nothing else), launch Tor, and display a bootstrap progress bar *inside* the browser window while it waits for Tor to download network data. Once we get to that point, I plan to make Vidalia an optional package for people who really want advanced configuration like also running a relay/bridge, watching the network map, etc. However, if your Tor Controller ends up being superior to Vidalia by then, I could easily see recommending it as the official "Advanced Controller" addon package, especially since it should be substantially less of a packaging burden than building and shipping all of Qt for several platforms (I hope). It will be pretty hard to convince me that we should continue shipping a separate Controller UI bundled with Tor Browser by default though, given the above issues. -- Mike Perry
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev