<p>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)</p>
<p>btw: are there already pics of the new ui? (is it the one from Nuno Pinheiro you are talking about?)<br></p><br><div><span class="gmail_quote">2008/2/7, Aaron J. Seigo <<a href="mailto:aseigo@kde.org">aseigo@kde.org</a>>:</span><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">
hi all...<br><br>so playing with runners i've noticed that it's going to take quite a bit of<br>manual tweaking and playing to get them "just right".<br><br>here are some thoughts i've been having:<br>
<br>* krunner should use solid to detect the # of cpu cores and expand the thread<br>pool accordingly (e.g. base + (2 * (num_cores - 1)))<br><br>* runners should be able to publish their syntax, so that it's discoverable<br>
that "spell plasma" actually does a spell check on it. i'm thinking a simple<br>QMap<QString, QString> syntax() or some such that would allow fetching<br>a "table" of syntax and descriptions from a runner.<br>
<br>* by default matches should not be relevance 1. maybe .6?<br><br>* we have two speed settings, and on the slow speed the object only gets<br>access to two of the threads. a seemingly abandoned approach was to ensure<br>
only one of each type (which of course still deadlocks when the # of unique<br>slow runners is equal to the number of threads) ... another approach is to<br>ensure that only one of each kind is running, with a maximum of N threads<br>
dedicated to them. this will prevent one really slow one from block all the<br>other slower ones.<br><br>* do we need more that two speeds? what would we do with these other speeds?<br><br>* we have a priority rating .. that seems to work ok, but it is set by the<br>
runner itself. we should probably audit each runner for its setting. but what<br>would be really great would be providing a mechanism that the *user* can<br>override. perhaps the priority rating should also be taken into consideration<br>
alongside relevance for final ranking in the UI?<br><br>* pulling some of the threading and runner management code out of KRunner's<br>Interface class and putting it into something semi-generic in libplasma (in<br>SearchContext, even?) would make it easier to use runners from elsewhere<br>
<br>* the runners that are currently built into krunner really should probably be<br>plugins so others can use them. it doesn't seem to offer any lessening of<br>risk since the plugins are loaded immediately not during run-critical points<br>
<br>* we need some interaction modes in krunner including: fixed search (can't<br>edit the search term; useful for user switching), single runner (only use one<br>specific runner; or maybe set of?) ...<br><br>* we really need that new UI ;)<br>
<br>--<br>Aaron J. Seigo<br>humru othro a kohnu se<br>GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43<br><br>KDE core developer sponsored by Trolltech<br><br>_______________________________________________<br>
Panel-devel mailing list<br><a href="mailto:Panel-devel@kde.org">Panel-devel@kde.org</a><br><a href="https://mail.kde.org/mailman/listinfo/panel-devel">https://mail.kde.org/mailman/listinfo/panel-devel</a><br><br><br></blockquote>
</div><br>