KRunner behavior change

[Aaron J. Seigo]

On Tuesday 01 April 2008, Matej Svejda wrote:
> I hacked on the KRunner-interface today and made a couple of changes:
>  * Removed the CompletionBox

>  * the default match is highlighted when typing

+ 1

>  * pressing tab in the SearchTermBox causes the next Match to be
> highlighted (bash-like)

this doesn't work here? i have to open the completion list first.. not so hot 
really.

i'd say simply setting the completion mode of the existing edit widget to 
KGlobalSettings::CompletionAuto or maybe KGlobalSettings::CompletionShell 
(i've never played with that one at all, tbh) should probably be enough and a 
lot easier to code than the hoops you've jumped though here =)

>  * instead KRunner now remebers what matches were launched and how
> often that happened (saves it in krunnerhistory)
>  * how often a match has been launched is considert when selecting the
> default match

this is a step in the right direction; i wonder, however, if just because i 
selected an item with a low relevancy previously if i want to keep picking 
that one ... i also wonder if this value to go up linearly in relation to 
number of executions.

more importantly, let's say that there are two search terms: T0 and T1. the 
set of returns for T0 and T1 intersect on match M0 and M1. if my pattern goes 
like this (search -> match selected):

T0 -> M0

do i now want M0 to pop up first when i do T1? or how about:

T0 -> M0
T1 -> M1

should M0 and M1 both rank equally for both search terms? or:

T0 -> M0
T1 -> M1
T1 -> M1
T1 -> M0
T0 -> M0

now it's really apparently that M1 should be returned for T1, but it won't be 
the default item?

it seems we really want a mapping of terms to matches, and a calculation that 
weighs both in relation to each other, thereby matching both global as well 
as specific search term instances.

i increasingly get the feeling that we're not going to get away with a simple 
kconfig based store for this data. a small queryable embedded database 
probably makes more sense from a flexibility and performance POV.

> * by default InformationalMatches are copied to the clippboard (and
> krunner is closed). This seems to be more runner-like (appear, type,
> get information, disappear opposed to apear, type, get information,
> stay ;-D).

this really does not work in the case of the calulator runner however. 
clobbering the clipboard behind the user's back is also not very nice 
behaviour. so, i think we'll skip on this one.

> * pastQueries has been removed from krunner.kcfg

so how do we keep state between executions of krunner? remember that 
queries != matches.

> * the data in the matches produced by the calculator-runner are now
> without the equals sign

... which is intentional, so that you can do multiple calculations in a row. i 
happen to use this on a regular basis, in fact, and was a requested feature.

> What I'm not happy with is how the uniqueIdentifier for a match is
> created. It is just RunnerName+text+subtext.

i'm not sure we want to drag subtext into it ... 

-- 
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/20080401/cba648ff/attachment.pgp