Translate Runner

[Aaron J. Seigo]

On Saturday 15 March 2008, Matej Svejda wrote:
> > showing something while the user is typing, if it doesn't still match the
> > search term, is meaningless. or at least, it can be meaningless.
> >
> > consider: search query is "translate en de i want beer" and then they
> > paste the text "gg:beer"; the translation is now irrelevant and even just
> > plain wrong.
>
> I think that showing something (even if there is a chance it might be
> irrelevant) is better than showing nothing. The way KRunner works now
> is that with slower runners you get the result at the end, when you're
> done typing. You don't get any feedback while you type.

for runners where the results may well stay the same, having long lived 
runners is probably a partial solution to this.

another improvement might be running slow runners further into the typing 
process so that they don't pile up on top of themselves/each other due to 
being run as many times as possible?

but abusing the matches list to show progress seems like trying to solve the 
problem in the wrong place. perhaps the UI could have an area that shows 
match activity?

but i honestly don't even know if this actually *matters* to users. does it 
matter to the user that .2s after typing $FOO but .1s ago a runner returned 
$BAR, even though that match is now no longer useful as the term is now 
$FOO+$BAZ?

so let's step back a moment and ask ourselves:

* what are the use cases?
* what is the real problem we're trying to solve here?

> > even worse: i want to launch the command "rmid" and so i type it an
> > press "enter" really quickly. the exec runner may well return "rm" after
> > i press enter but before it returns "rmmid" and now i'm running "rm"
> > instead of "rmid"! whoops!
>
> Well this could be worked around easily: Just make sure that the
> action at the top when pressing enter is the result of the full query,
> not just of one a part of it.

the "action at the top" is not guaranteed to be the one that gets selected. 
there are other things that can influence it such as whether the action is 
enabled, etc. 

it's also just plain odd to have an entry shown in the list that doesn't 
actually match what is being shown and then to have it simply disappear at 
some undetermined future point.

if it is fast enough to reach the lower list and a runner is slow enough this 
could even result in a "dead" action that the user may select but which 
doesn't actually do anything useful (or worse: something rather unexpected)

this also means filtering them at the UI and not in the SearchContext.

it just feels very, very rough and brittle.

> > only the runner knows if it retains its meaning and we by default assume
> > the answer is "no".
>
> But "no" is not the right answer (in most cases). The most common
> scenario for the usage of KRunner is that the user types a query and
> then presses enter (or selects an action and then presses enter). And
> in that case results based on an incomplete query make sense.

it's not about how often that's the wrong answer, but what happens when it's 
the right answer. the answer to that is buggy behaviour. ("that wasn't what i 
typed." or "that match doesn't related to my query".)

of course, if we just populate the matches list with whatever is given at the 
end of the last run for a given runner, then we could re-process that match 
with the new search query and avoid most of this problem. but that means:

 * the match list is now no longer definitive but purely speculative
 * the match list will end up populated with *lots* of false positives
 * adding to the API so that runner must be able to reprocess an existing 
match with a new search term

as for the "most common scenario", i'm not sure that's accurate either. of the 
current runners, the following fit that pattern pretty well:

* WebShortcuts
* LocationsRunner

and .. the rest all seem to be able to change pretty radically based on the 
full entry.

something i've considered is whether or not the following set:

	http:
	http://www.
	http://www.kde.org

could be more efficiently/easily dealt with if the match itself wasn't 
destroyed and recreated each time but simply appended to. 

thing is that the runner is still the only one that knows this, and is the 
only place this can be known. so runs still need to be made to the runner in 
this case.

an improvement here would be (again) long-lived SearchMatches that live longer 
than each run. but that's the only part (the destruction and creation of 
matches when all that's happening is the existing match is getting appended 
to).

but even long-lived matches will bring some speculative nature to things as we 
need to go back to the runner to ensure they remain accurate.

keeping the match list as an actually accurate list is pretty important if the 
UI is ever to be made quicker to use.

> > i don't think that's true. if the number of slow runners >= number of
> > threads, we can end up with unecessary waits by having all the threads
> > utilized by slower runners. we will always want to have a "fast lane"
> > thread(s) for non-slow runners due to this.
>
> I guess your right. I was thinking that each runner would run in a
> separate thread, no matter how many cores the processor has. I forgot
> that KRunner tells ThreadWeaver to create one thread per core.

one thread per core + 2.  and yes, we absolutely must limit the number of 
threads otherwise it becomes unusable on smaller systems or shared systems 
(e.g. LTSP)

-- 
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/9e2d154e/attachment-0001.pgp