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@kde.org > https://mail.kde.org/mailman/listinfo/plasma-devel _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
