SearchMatch::HelperMatch and/or relevancy == 0?

Aaron J. Seigo aseigo at kde.org
Sun Mar 16 00:26:24 CET 2008


hi...

right now we have three "kinds" of matches for runners to provide: 
Informational, Possible and Exact.

there's an interesting problem when we have runners such as the search runner 
which always provide a "Search for..." entry that is generic to the query. i 
can see the same thing happening eventually for any learning runner that 
wants to offer a "Learn '$QUERY'" entry.

the problem this creates is that if i type "www.kde.org<enter>" with the space 
between the 'g' and the <enter> being smaller than the time it takes to 
populate the returns .... then the spurious "Search for..." entry gets 
selected instead.

to avoid this there was a hardcoded (!) check for more than one entry on 
<enter> triggered matches. obviously without the search runner this breaks 
things right now, and when there is more than one search runner like beast 
out there that check wouldn't be enough (so bringing it back then is 
useless). and once runners are conifgurable in the UI, the moment someone 
turns off all those runners, we're back to wanting the count to == 0. 

so there are a couple low-impact possibilities i can see:

a) not auto-selecting matches with a relevancy of 0.

b) introduce a HelperMatch type in addition to Informational, Possible and 
Exact which mark this entry as a Helper

the nice thing about the relevancy == 0 approach is that it's easy, requires 
no API changes and has the added effect of keeping all these at the bottom of 
the list with no further coding.

the nice thing about the HelperMatch tag is that we know that they are indeed 
a "Helper" match[1] which means we may decide to do things like keep them 
around for the entire span of the query session rather than keep recreating 
them. it also means that we can sort them to the bottom of the list, but also 
use relevancy to sort between them so that "more relevant" (whatever that 
might mean for the query and runner) Helpers can be moved up the list.

it's possible to also do both: don't auto-activate if relevancy == 0 and have 
items marked as "Helpers".

[1] i've defined helper match in a draft apidox as: " A match that represents 
an action not directly related to activating the given search term, such as a 
search in an external tool or a command learning trigger. Helper matches tend 
to be generic to the query and should not be autoactivated just because the 
user hits "Enter" while typing. They must be explicitly selected to· be 
activated, but unlike InformationalMatch cause an action to be triggered."

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Trolltech
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/panel-devel/attachments/20080315/741f4050/attachment-0001.pgp 


More information about the Panel-devel mailing list