4.5 polishment: krunner (under_the_hood)

[Lukas Appelhans]

Am Sonntag 07 März 2010 15:39:14 schrieb Jacopo De Simoi:
> Hi there, this is the first part of my ideas for polishing krunner for 4.5.
> This thread will focus mostly about under_the_hood (i.e. not UI) changes,
> sooo here are my ideas:
> 
> * Better sorting: at the moment krunner remembers which items the user runs
> frequently and kicks them up in the results list. While this works well in
> principle, it has some drawbacks, let me give a few examples: I run quite
> often konsole via krunner, and now, whenever I look for "system", konsole
> comes up first, because it belongs to the "system" category and it has an
> enormous boost due to the extremely high run count. Moreover I might look
> for xterm and write "term..", but still konsole would win. Also, I run
> gwenview pretty often with krunner and it always shows up first when
> looking for "view", same thing for emacs and looking for "GNU".
> 
> My proposal is the following: when obtaining a succesful partial match
> (e.g. "kon" for "konsole", "kma" for "kmail" "sys" for "system settings")
> we store somewhere (in the querymatch?) not just the exact query (i.e.
> "kon", "kma", "sys") but the minimum completion of our partial query in
> the string (i.e. "konsole", "kmail", "system"). We will then keep track of
> the number of times a pair (match_id, "completed query") has been called
> instead of just the match_id. Notice that we actually need the word(s)
> containing the query for this to be useful, otherwise "kon" "kons"
> "konso", willl all add up to different counters, which is suboptimal. In
> any case this would imho allow krunner to better guess that the user wants
> to run for a given query.
Hey!

Well I have a patch for sorting the Application Runner already done... (via 
storing stuff in Nepomuk)... so we may reuse it? :) It's already splitted into 
a separate lib... (the thoughts behind it were done by Ivan & me at tokamak)

I can give a patch if needed of course... it's just a matter of porting it 
from the app-runner to main KRunner...

Lukas
> 
> * Better sorting II: at the moment the boost in relevance is linear in the
> number of runs (saturated to 1.0), therefore even partial matches can
> overcome exact matches if their corresponding entries have a very high run
> count.
> 
> My proposal is to fix some given ranges for each match type (e.g. partial
> match, exact match, possible match) and saturate to the maximum allowed
> for this range instead that to 1.0; As a bonus the boost could be made
> quite easily non-linear in such a way that the saturation is smooth and
> not abrupt.
> 
> * Safer i18n support: a fix which got in just a little bit before release
> has to do with i18n. The issue here is that krunner is supposed to
> understand commands given in the user language. several runners try to
> obtain command parameters parsing the queries (e.g. the powerdevil runner
> accepts "power governor /performance/" and /performance/ is supposed to be
> a parameter; the solid runner accepts "mount /device/" and /device/ is a
> parameter). Most runners accomplish this task by splitting the query in a
> stringlist and then grabbing the relevant word(s). Of course this works in
> en_US, but possibly not in other languages, since the number of strings
> may vary, or the spaces between words may not be given by %20, who
> knows...
> 
> My proposal (thanks to a suggestion by Albert) is to make sure that each
> runner uses proper regular expressions for parameter extracting (afaict,
> the only runner featuring this in a (hopefully) correct way is the
> powerdevil runner).
> 
> As always, other ideas, comments or thoughts are more than welcome!
> Regards
> 
> __J
> _______________________________________________
> Plasma-devel mailing list
> Plasma-devel at kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel