Translate Runner

[Matej Svejda]

> another option  would be to use a local event loop.. e.g.:
Sounds good, I'll do that.

> btw, you're leaking m_http in your code right now every time a match is done.
> you should delete it (and zero the pointer for safety) in the requestDone
> slot.
Damn it... I'm really used to languages with garbage-collectors...

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

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

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

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

> yours is the one i'm thinking of.
;-D