[tor-bugs] #3144 [Vidalia]: Network panel : Improve router list usability

[Tor Bug Tracker & Wiki]

#3144: Network panel : Improve router list usability
-------------------------+--------------------------------------------------
 Reporter:  tvataire     |          Owner:  tvataire
     Type:  enhancement  |         Status:  assigned
 Priority:  normal       |      Milestone:          
Component:  Vidalia      |        Version:          
 Keywords:               |         Parent:          
   Points:               |   Actualpoints:          
-------------------------+--------------------------------------------------

Comment(by tvataire):

 Replying to [comment:6 chiiph]:
 > Replying to [comment:5 tvataire]:
 > > Replying to [comment:4 chiiph]:
 > > > Replying to [comment:3 tvataire]:
 > > > I think it's better if the search is always with
 Qt::MatchStartsWith. It would simplify onRouterSearch() a bit, and since
 you don't actually filter the router list, I think it will lead to the
 same behavior you have right now.
 > > >
 > >
 > > I'm not sure. Currently routers whose names match exactly the searched
 string are selected in priority. Qt::MatchStartsWith is only used as an
 alternative when Qt::MatchExactly fails.
 > > Always use Qt::MatchStartsWith will select all these routers without
 distinction, isn't it ?
 > > Do you see a reason to favor this behavior ?
 >
 > Routers currently are sorted by bandwidth by default, you can change
 that order by clicking in the columns. I assume that when you search with
 MatchStartsWith, it will give "priority" to the first match in the current
 order, right? This seems like a nice "feature", you can change how it
 searches by just clicking in the columns and changing the order.
 >
 > Either way, I think that if you have something like this:
 > {{{
 > name1
 > name
 > name2
 > }}}
 > you type "name", and it selects the second router, and then the first
 one, and then the third one, it's a really odd behavior, don't you think?
 > Anyway, I think that up to this point we both understand what we think
 about the usability part of this feature :)
 >

 ok, I better understand your point of view.
 I chosen this behavior to avoid to have to sort the list by name before
 doing a search, but I agree, this isn't intuitive.

 > >
 > > Progressive search would be a good feature.
 > >
 > > Here is what I propose :
 > > - implement progressive search
 > > - allow to find next matching item by pressing return key (if several
 routers have the same names or if their names start with the same pattern)
 >
 > Yes, that's a nice idea.
 >
 > >
 > > I didn't used the signal QLineEdit::returnPressed() because it doesn't
 allow to transmit the name of the router to search for.
 > > The only way I see to use it is :
 > > - to connect the NetViewer class to this signal
 > > - when the signal is emited, the NetViewer class retrieve
 QLineEdit::text(), then calls RouterListWidget::onRouterSearch(QString
 routerNickname)
 >
 > You could just change onRouterSearch to
 RouterListWidget::onRouterSearch(), then connect
 QLineEdit::returnPressed() to it, and on the first line of onRouterSearch
 you could do:
 > {{{
 > QString routerNickname = somelineedit.text();
 > }}}
 > and the rest of the slot stays the same.

 ok I'll try this.

 > You hook up this same slot to returnPressed and textChanged to support
 progressive search. I'm not sure if you connect it to textChanged only,
 what would happen when you press return. Or you can just do what you said
 :)

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