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 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 :)

 >
 > 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. 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:6>
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