refiining runners

[Bernhard]

this would also open up the possibility to use the runners in  the menu
(kickoff) which would be really great... I'm really missing it to just type
a command into kickoff and get the option to run it (just like it works in
krunner and kickoff kde3)

btw: are there already pics of the new ui? (is it the one from Nuno Pinheiro
you are talking about?)

2008/2/7, Aaron J. Seigo <aseigo at kde.org>:
>
> 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
>
> _______________________________________________
> Panel-devel mailing list
> Panel-devel at kde.org
> https://mail.kde.org/mailman/listinfo/panel-devel
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/panel-devel/attachments/20080207/34506354/attachment-0001.html