4.5 polishment: krunner (under_the_hood)

[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.

* 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