Re: [tor-dev] Vidalia 2.0 - an complete rewrite

2013-02-20 Thread adrelanos
I think if it become as good as Vidalia and better, that would be most welcome. Questions are: * What is missing in Vidalia? * Why has development of Vidalia stopped? * Time to switch to python? * Time for a rewrite or better improve the existing code base? Before developing it, I'd make a list

Re: [tor-dev] Vidalia 2.0 - an complete rewrite

2013-02-20 Thread Damian Johnson
> So i started to rewrite it from scratch and i am close to the release of > the source code. That would be... quite a substantial project. Kamran Khan, a GSoC student from a couple years back, did a GTK controller in python. What language did you use? How long have you been working on this, and b

Re: [tor-dev] Vidalia 2.0 - an complete rewrite

2013-02-20 Thread Nick Mathewson
On Wed, Feb 20, 2013 at 2:37 PM, Leo Unglaub wrote: > Hey friends, > i want to inform you that i am working on a complete new control tool > for Tor. I know some people use Vidalia for it, but i never liked the > program and the people i showed vidalia often got confused. It sounds like a cool pr

Re: [tor-dev] Vidalia 2.0 - an complete rewrite

2013-02-20 Thread Greg Norcie
This sounds really cool. I've found in my user studies that Vidalia can be confusing to users (since Vidalia and the TBB are two different application windows) Is that an issue you're trying to solve in your rewrite? (Reference, if you want some background: http://petsymposium.org/2012/papers/ho

[tor-dev] Vidalia 2.0 - an complete rewrite

2013-02-20 Thread Leo Unglaub
Hey friends, i want to inform you that i am working on a complete new control tool for Tor. I know some people use Vidalia for it, but i never liked the program and the people i showed vidalia often got confused. So i started to rewrite it from scratch and i am close to the release of the source c

Re: [tor-dev] Proposal: Controller events to better understand connection/circuit usage

2013-02-20 Thread Damian Johnson
Gotcha. I'd still advise against it. Controllers can certainly parse that kind of response, but it sucks for users. Stem's ORCONN event handling is suckier than most because of it. https://gitweb.torproject.org/stem.git/blob/HEAD:/stem/response/events.py#l631 __

Re: [tor-dev] Proposal: Controller events to better understand connection/circuit usage

2013-02-20 Thread Karsten Loesing
On 2/20/13 5:13 PM, Damian Johnson wrote: >> In general, I agree. Here, I re-used the code that adds a LongName or >> Target to CIRC events. It's a single function call that returns the >> best information tor has about the remote end of a connection. > > I'm not sure that I follow. Do you mean

Re: [tor-dev] Proposal: Controller events to better understand connection/circuit usage

2013-02-20 Thread Damian Johnson
> In general, I agree. Here, I re-used the code that adds a LongName or > Target to CIRC events. It's a single function call that returns the > best information tor has about the remote end of a connection. I'm not sure that I follow. Do you mean the Path attribute of CIRC events? If so then tha

Re: [tor-dev] Tor Browser Launcher

2013-02-20 Thread adrelanos
Micah Lee: > On 02/19/2013 06:39 PM, adrelanos wrote: >>> What operating system are you using? >> >> Debian Wheezy. > > Weird, that's what I'm running Wheezy too. But just to be safe, I > decided I'd make a new Debian Squeeze vm and try to build it and run it > in there. I found several small prob