refiining runners

[Aaron J. Seigo]

hi all...

so playing with runners i've noticed that it's going to take quite a bit of 
manual tweaking and playing to get them "just right".

here are some thoughts i've been having:

* krunner should use solid to detect the # of cpu cores and expand the thread 
pool accordingly (e.g. base + (2 * (num_cores - 1)))

* runners should be able to publish their syntax, so that it's discoverable 
that "spell plasma" actually does a spell check on it. i'm thinking a simple 
QMap<QString, QString> syntax() or some such that would allow fetching 
a "table" of syntax and descriptions from a runner.

* by default matches should not be relevance 1. maybe .6?

* we have two speed settings, and on the slow speed the object only gets 
access to two of the threads. a seemingly abandoned approach was to ensure 
only one of each type (which of course still deadlocks when the # of unique 
slow runners is equal to the number of threads) ... another approach is to 
ensure that only one of each kind is running, with a maximum of N threads 
dedicated to them. this will prevent one really slow one from block all the 
other slower ones. 

* do we need more that two speeds? what would we do with these other speeds?

* we have a priority rating .. that seems to work ok, but it is set by the 
runner itself. we should probably audit each runner for its setting. but what 
would be really great would be providing a mechanism that the *user* can 
override. perhaps the priority rating should also be taken into consideration 
alongside relevance for final ranking in the UI?

* pulling some of the threading and runner management code out of KRunner's 
Interface class and putting it into something semi-generic in libplasma (in 
SearchContext, even?) would make it easier to use runners from elsewhere

* the runners that are currently built into krunner really should probably be 
plugins so others can use them. it doesn't seem to offer any lessening of 
risk since the plugins are loaded immediately not during run-critical points

* we need some interaction modes in krunner including: fixed search (can't 
edit the search term; useful for user switching), single runner (only use one 
specific runner; or maybe set of?) ...

* we really need that new UI ;)

-- 
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/20080207/59d78d01/attachment.pgp