[tor-bugs] #2905 [Vidalia]: Adapt Vidalia UI to allow users to avoid connecting to the public tor network

Tor Bug Tracker & Wiki torproject-admin at torproject.org
Mon Jun 13 14:33:11 UTC 2011


#2905: Adapt Vidalia UI to allow users to avoid connecting to the public tor
network
---------------------+------------------------------------------------------
 Reporter:  anonym   |          Owner:  chiiph         
     Type:  defect   |         Status:  new            
 Priority:  major    |      Milestone:  Vidalia: 0.2.13
Component:  Vidalia  |        Version:  Vidalia 0.2.10 
 Keywords:  bridges  |         Parent:                 
   Points:           |   Actualpoints:                 
---------------------+------------------------------------------------------

Comment(by anonym):

 Replying to [comment:16 chiiph]:
 > Trying to merge both ideas, we could do something like this:
 >
 > {{{
 > if it's the first time you execute Vidalia:
 >    show network config dialog with a label that says something like what
 mikeperry said
 > elif if usebridges is configured but there are no bridges:
 >    show network config dialog with a label asking the user to either add
 bridges, or just disable them
 > else:
 >    start vidalia as usual, and if the user checks "My ISP blocks..." but
 doesn't add bridges, just ignore this with a warning.
 > }}}
 Is there any reason for why you want to stick with the stuff in the
 "else:" part (i.e. "if the user checks 'My ISP blocks...' but doesn't add
 bridges, just ignore this with a warning")? What that suggests is
 precisely going back to the old behaviour you described in #3354, which I
 feel is very confusing and unintuitive. Why should an option that is set
 when you open the Vidalia settings suddenly revert when pressing Ok even
 though you haven't touched itm or any related options?

 My [comment:12 suggestion] captures both the case when you start Vidalia
 and when you reconfigure Vidalia in the settings since both of these call
 ConfigDialog::applyChanges(). My suggestion
  * wouldn't add any more complexity to code -- in fact the code would be
 put in the same place (ConfigDialog::applyChanges()) instead of two places
 (one for startup, one for when saving settings).
  * has only one prompt dealing with this instead of two, which is more
 consistent for the user.
  * does not confuse the user as I think #3354's behaviour does.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/2905#comment:17>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online


More information about the tor-bugs mailing list