Things to complete for 0.1.0: * Stop using 'getinfo network-status' to get a list of servers. Instead, we should be using 'getinfo ns/all' (Tor >= 0.1.2.3-alpha). * There is a ticket about not being able to save config changes when an alternate torrc is specified. Needs to be verified and fixed. (Ticket #159) * We should close any logs that have 'stdout' or 'stderr' as the target after we connect to Tor's control port, but pass command line arguments to Tor to tell it to log to stdout and stderr initially, in case it dies before we can connect to its control port. This way, if Vidalia freezes, Tor won't freeze. * Start using the DESCCHANGED event to find out when our own descriptor changes, if the user is running a server. Features planned for 0.1.x: * Our GeoIP cache should recognize IP addresses on the same subnet. (Ticket #154) * GeoIP requests should be encrypted so the exit node does not know what is being requested and cannot muck with the requests or responses. * Roger has added some additional events that Vidalia should respond to, such as "hey, you're a server now!" * Scheduled rate-limiting, so the user can adjust their bandwidth limits depending on what time of day it is. * An interface for letting the user send arbitrary signals to Tor. The phase 1 GUI competition judges didn't like the idea, but our users and Roger seem to like the idea. Oh what is a Vidalia developer to do? * Provide an interface for configuring all torrc options. This might look something like a table, populated via "getinfo config/names". (Ticket #76) * A web-based interface for viewing the status of Tor from the user's browser and possibly configuring Tor, too. (Ticket #42) * We should support and use the ControlSocket option whenever possible. * No sooner did we add support for 'getinfo addr-mappings' than did 'getinfo addr-mappings' become deprecated. We should move to the shiny new 'getinfo address-mappings' instead (cool kids don't abbreviate). Packaging: * Create a Vidalia package for Debian. * The general consensus so far has been that Polipo is better/faster than Privoxy, so we should start thinking about moving to Polipo. Ideally, Vidalia will launch Polipo in the background just like it does Tor so the user doesn't have to know that Polipo exists and Windows users don't have another icon cluttering their tray. * Building a Windows bundle installer is a bit of a pain initially, since you have to create a bunch of specifically-named directories and copy files from Vidalia's svn directory. Can we make this easier? For example, maybe we could make a batch file that takes as arguments paths to the Tor, Privoxy, and Vidalia installers, and then produces a completed bundle installer. Localization: * Website and wiki. The website shouldn't be too hard since we only have a couple pages, but it doesn't look like Trac lends itself to multiple languages on the wiki too easily. * OS X installer. Is there a standard way OS X handles installer translations? I assume we'd mostly just need to translate our little VidaliaBundleWelcome.rtf file and maybe a couple strings in the .plist files, but how does the user choose which language they want to see? Miscellaneous Tasks: * We should work much harder specifying what Vidalia does. When we add a feature that interacts with Tor, we should specify exactly which control commands we're sending, where in the UI the values come from, what we ask Tor to populate certain widgets, etc. This has the added benefit of making it easier for other non-developer type folks to write and maintain our help docs. * Work on improving the network map with better graphics, server pinpoints that are more visible and clickable, and clickable circuits. Marble might be a good start for some of that. * When creating the Tor service on Windows, we either should be creating a separate user to run the service as (instead of running it as Local System), or we should write a patch for Tor to do it (Ticket #174). * We should parse the Tor log messages we pipe from stdout and look for errors or warnings, so we can give better error messages (e.g., "Hey, you probably already have a Tor running without a control port open."). Suggested by Karsten Loesing. * Improve window transparency support. In particular, figure out how to do the following correctly on X11 (from the Qt docs): "This feature is available on Mac OS X, X11 platforms that support the Composite extension, and Windows 2000 and later. Note that under X11 you need to have a composite manager running, and the X11 specific _NET_WM_WINDOW_OPACITY atom needs to be supported by the window manager you are using." * Think about smarter ways to handle the GeoIP lookups. Our servers get quite a bit of traffic from GeoIP lookups and it would be nice if we could cut this back a bit. * Get some help from the Sasha and the CMU folks with doing a real user study and getting help making our window layouts and text better. * Rework src/control/ a bit so it is more modular and can be dropped into any other Qt application that wants to talk to Tor. * Add a --disable-qsystrayicon autoconf option to build with our own tray icon implementation with Qt 4.2, instead of using QSystemTrayIcon. * The 'Save' button in the config dialog should be grayed out until the user actually changes some settings. * We should have a Windows shell script file to build Vidalia, similar to our auto* stuff, except the user doesn't need to install Cygwin, MSYS, or similar. In practice, this really would just run 'qmake' and 'lrelease' for now. * We need to come up with a simple set of instructions for Windows users to give us helpful information when their Vidalia crashes. The standard Windows error messages are not useful, so we need to tell Windows folks how to get a backtrace. This may also involve telling them to first download a Vidalia binary with debugging symbols before reproducing their crash. * If we get rid of Privoxy, it would be good to have a set of tray and dock icons for Vidalia that show some sort of activity when the user is actively using Tor. * To build Vidalia as a qmake-generated XCode project, one needs to set USE_HEADERMAP=0. We should figure out why this is and either fix it, or find a way to make qmake generate an XCode project with this build setting already set. Notes from Roger: * It looks like we need to restart Vidalia to get a new language choice to take effect. This means restarting my Tor, which will break my current Tor activity. I know it's probably a hassle to make it change languages without a restart, but it will make our foreign users a lot happier.