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

["Tor Bug Tracker & Wiki" <torproject-admin@xxxxxxxxxxxxxx>]

#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:4 chiiph]:
 > Replying to [comment:3 tvataire]:
 > > The patch search_lineEdit.patch provides an other way to search a
 router in the routers list :
 > >
 > > It adds a search field above router list, allowing to search a router
 by it's nickname.
 > >
 > > First, search is made for routers whose name match exactly the string
 of the search field.
 > > If no match is found, search is made for routers whose name start with
 the string of the search field.
 >
 > 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 ?

 > >
 > > Searches are case-insensitive.
 > >
 > > Searches are triggered by pressing Key_Enter or Key_Return.
 >
 > Another possibility that might make this code even cleaner would be to
 use the signal:
 > {{{
 > void QLineEdit::textChanged ( const QString & text ) [signal]
 > }}}
 > in RouterListWidget and you'll have a progresive search.
 >
 > And yet another possibility would be to use:
 > {{{
 > void QLineEdit::returnPressed () [signal]
 > }}}
 > which would lead to the same behavior you have in the patch, with less
 code.
 > (The signals would be connected to
 RouterListWidget::onRouterSearch(QString routerNickname), although
 depending on the signal used you'd have to change the parameters)

 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)

 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)

 Do you think this solution is better ? Is there an other way that I missed
 ?

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/3144#comment:5>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs