<br><br><div class="gmail_quote">On Wed, May 7, 2008 at 5:43 PM, Ryan P. Bitanga <<a href="mailto:ryan.bitanga@gmail.com">ryan.bitanga@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi,<br>
<br>
My patch will be a little bit delayed yet again due to conflicting<br>
changes in libplasma. My patch reenabled queue timers for<br>
Interface.cpp but Aaron fixed that in RunnerManager a short while ago.<br>
Similarly I also used id() for getting KPluginInfo->pluginName because<br>
I needed it for reloading configs of a specific runner.<br>
</blockquote><div>?<br>Where? AbstractRunner already has the name() method and if you added the reparseConfiguration method I don't know why you need that outside AbstractRunner.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
For everyone's benefit (and to prevent further delays in my patch), I have:<br>
<br>
* Added a reparseConfiguration method to AbstractRunner to reload the<br>
config of a specific runner.<br>
* Got rid of runner phase. Use<br>
setPriority(AbstractRunner::HighestPriority) for first runners, etc.<br>
instead<br>
* Got rid of the blacklist and revamped the load function. (Whitelists<br>
make more sense since the default behavior should be "plugin disabled<br>
by default" ie X-KDE-PluginInfo-EnabledByDefault=false)<br>
</blockquote><div><br>That will mean that when installing a new runner any program using runners should be configured to use it...<br>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. <br>
<br></div><div> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Just a little question, what did we gain by sharing searchcontext? The<br>
point of performMatch and local searchcontexts was to reduce the locks<br>
on the searchcontext. Currently, we still lock everytime we add a<br>
match and DataPolicy is useless.</blockquote><div><br>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. <br>
</div></div><br clear="all"><br>-- <br>Jordi Polo Carres<br>NLP laboratory - NAIST<br><a href="http://www.bahasara.org">http://www.bahasara.org</a><br>