Translate Runner

[Aaron J. Seigo]

On Saturday 15 March 2008, Matej Svejda wrote:
> What I haven't figured out yet is why TranslateRunner::exec() is never
> called. I'd use this method to write the translated text into the

missing "const" on the second parameter. it was:

void exec(const Plasma::SearchContext *context, Plasma::SearchMatch *action);

and should have been:

void exec(const Plasma::SearchContext *context, const Plasma::SearchMatch 
*action);

whoops! =)

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 =)

it's perfectly ok for a runner to block.

which does bring up the interesting tangential topic of improved strategies 
for calling AbstractRunner::match. there are various common strategies, 
including:

* only if there are more than N letters (e.g. 3)

* only after N more letters than the last lookup are entered or the user 
is "done" (to avoid repeated lookups; we do manage this somewhat in krunner 
itself by having a small timeout between typing and lookups, but some runners 
may well want a bigger time gap as their lookups may be expensive and 
non-critical)

* no more than once every N ms (to avoid repeatedly banging on a network 
service, for instance)

* ...?

* some combination of the above

right now it's up to individual runners to implement these strategies. that 
means more work for the runner author and high utilization of the thread pool 
often unnecessarily. i wonder if it would make sense at some point to provide 
a way for runners to define their match strategy and have it assumed to be 
respected by the host application?

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.

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