KRunner config dialog

[Jordi Polo]

On Wed, May 7, 2008 at 5:43 PM, Ryan P. Bitanga <ryan.bitanga at gmail.com>
wrote:

> Hi,
>
> My patch will be a little bit delayed yet again due to conflicting
> changes in libplasma. My patch reenabled queue timers for
> Interface.cpp but Aaron fixed that in RunnerManager a short while ago.
> Similarly I also used id() for getting KPluginInfo->pluginName because
> I needed it for reloading configs of a specific runner.
>
?
Where? AbstractRunner already has the name() method and if you added the
reparseConfiguration method I don't know why you need that outside
AbstractRunner.


>
> For everyone's benefit (and to prevent further delays in my patch), I
> have:
>
> * Added a reparseConfiguration method to AbstractRunner to reload the
> config of a specific runner.
> * Got rid of runner phase. Use
> setPriority(AbstractRunner::HighestPriority) for first runners, etc.
> instead
> * Got rid of the blacklist and revamped the load function. (Whitelists
> make more sense since the default behavior should be "plugin disabled
> by default" ie X-KDE-PluginInfo-EnabledByDefault=false)
>

That will mean that when installing a new runner any program using runners
should be configured to use it...
IMHO, blacklisting is better. If a new program that uses runners is
installed it will use every runner of the system unless specifically stated
otherwise by the user.



> Just a little question, what did we gain by sharing searchcontext? The
> point of performMatch and local searchcontexts was to reduce the locks
> on the searchcontext. Currently, we still lock everytime we add a
> match and DataPolicy is useless.


We also locked previously when calling addMatchesTo(), the main benefict is
that local SearchContext share the data instead of copying it. So we have
effectively _one_ shared list instead of a global list where multiple local
list copied their data.



-- 
Jordi Polo Carres
NLP laboratory - NAIST
http://www.bahasara.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/panel-devel/attachments/20080507/78ed567c/attachment-0001.html