Translate Runner

[Aaron J. Seigo]

On Saturday 15 March 2008, Matej Svejda wrote:
> > whoops! =)
>
> My bad... ;-D No it works. I also added setSubtext and uploaded the
> changes. Could you maybe add the runner to playground?

you could. it's your code =)

http://techbase.kde.org/Contribute/Get_a_SVN_Account

> > one bit of feedback i have is that runners are meant to run in a separate
> > thread, so i don't know if there's any real win to putting Translator in
> > its own thread other than to increase the number of threads being used =)
>
> Well the problem is that this runner uses QHttp which works
> asynchronously. Putting this into a separate thread with it's own
> event-loop and waiting in match() for this thread to finish seemed to
> me like the only possible choice. Or is there some other way?

KIO is one option as it provides a synchronous method (exec()). another option 
would be to use a local event loop.. e.g.:

m_eventLoop = new QEventLoop(this);
m_http.get(m_get);

and then in the requestDone slot do:

m_eventLoop->exit();

that should result in the same effect without the overhead of a thread.

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.

> About smarter strategies for calling match():
> This is one area where KRunner could definitely improve. Lot's of

agreed. (i committed a couple of Obvious Improvements, but they were simple 
things / low hanging fruit)

> resource-wasting here. As far as I understand it (from looking at the
> code) the way KRunner handles queries is that after a certain time for
> each known runner a new instance of that runner is created and the
> match function for that runner is executed in a ThreadWeaver-job (is
> that right?). So it can happen that if the user types at a decent
> speed instances of slow runners pile up. 

yes; we do try and limit this effect by limiting the number of slow runners we 
run at any given time.

> What I think could work better is to have only one instance per runner
> and a stack of queries (also one for each runner). So each time a
> runner finishes a match for one query it looks at the stack. If it's
> not empty it takes the query at the top, clears the stack and calls
> match for that query, otherwise it does nothing.

you don't really need a stack even, since you only need one entry there. in 
fact, you could probably get away with a simple bool: whether a match was 
attempted during running. if so, the runner could simply be re-primed with 
the current SearchContext. 

this of course requires that we then have a mechanism to know that a runner is 
in a match cycle. currently we don't, but that's not hard to add.

> That way we can avoid 
> runners building up (which might not be an issue now but might become
> if we have more runners) and also give slow runners enough time to at
> least display something while the user is still typing, not just when
> he's done.

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.

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!

only the runner knows if it retains its meaning and we by default assume the 
answer is "no".

i think that slow runners could do well to utilize long-lived matches (see my 
other mail on this topic) intelligently to help out with this (so that if the 
match wouldn't change due to the search term text change, the slow runner can 
just update the existing match as a "short path"). this would allow a runner 
to "reserve" a match as possibly meaningful between search match changes and 
then update or invalidate it.

> Also KRunner won't have to worry about whether a runner is 
> fast or slow.

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.

> >this itself probably requires pulling out this sort of code from
> >krunner/interface.cpp to a match manager class, which is already one of
> > the SoC proposals.
>
> Do you have any details on that? My proposal kind of overlaps with that...

yours is the one i'm thinking of.

-- 
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/10022704/attachment.pgp