<br>Your proposal has striking similarities to mine:<br><a href="http://www.bahasara.org/raw-attachment/wiki/Papers/gsoc.txt">http://www.bahasara.org/raw-attachment/wiki/Papers/gsoc.txt</a><br><br>It seems that even when both want to push krunner forward, you are more interested in the performance of the future krunner and I am more interested in the integration with the rest of KDE and the command input.<br>
<br>You wrote that ranking will be the most time consuming operation. I really see discovering the type of information or other text manipulation task as more consuming than ranking. Keep track of most used runners, add blacklisting and priority and rank according to that should not take a lot of time (guess what the kernel does with memory pages...)<br>
<br>I do like your idea of the runners being able of somehow present themselves and their syntax. <br><br><div class="gmail_quote">On Mon, Mar 31, 2008 at 5:53 AM, Matej Svejda <<a href="mailto:mata@aw-modell.at">mata@aw-modell.at</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;">Am Sonntag, 30. März 2008 21:48:58 schrieb Aaron J. Seigo:<br>
<div class="Ih2E3d">> please be sure to file this soon enough on <a href="http://code.google.com/soc2008" target="_blank">http://code.google.com/soc2008</a><br>
> so that you don't miss the deadline. now.. feedback:<br>
</div>Already did.<br>
<div class="Ih2E3d"><br>
> just to be clear, this won't work for all slow runners. i'm not even sure<br>
> this will help at all since these runners should be checking for this catch<br>
> word and returning immediately if it doesn't exist anyways. what this would<br>
> save is starting them in the thread; i'm not sure that's really a<br>
> bottleneck.<br>
</div>You're right. That's not really a bottleneck. But still if the catch-word was<br>
made configurable there is no real reason why a runner that only reacts to a<br>
catch-word should be instanciated an do the logic itself. This can be done by<br>
the manager-class. While this won't have a (noticable) impact on speed it<br>
would at least mean less work for the runner-programmers.<br>
I tried to clear that up a bit in my proposal.<br>
<div class="Ih2E3d"><br>
> the runner classes will remain part of libplasma. there's no material<br>
> benefit to having a second library just for this functionality, thought<br>
> having separate libraries to link against will increase the time to<br>
> startup.<br>
</div>Ok. Changed that.<br>
<br>
Thanks for your input!<br>
<font color="#888888"><br>
Matej<br>
</font><div><div></div><div class="Wj3C7c">_______________________________________________<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" target="_blank">https://mail.kde.org/mailman/listinfo/panel-devel</a><br>
</div></div></blockquote></div><br><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>