Idea for SoC propsal

Jordi Polo mumismo at gmail.com
Mon Mar 31 03:02:42 CEST 2008


Your proposal has striking similarities to mine:
http://www.bahasara.org/raw-attachment/wiki/Papers/gsoc.txt

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.

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...)

I do like your idea of the runners being able of somehow present themselves
and their syntax.

On Mon, Mar 31, 2008 at 5:53 AM, Matej Svejda <mata at aw-modell.at> wrote:

> Am Sonntag, 30. März 2008 21:48:58 schrieb Aaron J. Seigo:
> > please be sure to file this soon enough on
> http://code.google.com/soc2008
> > so that you don't miss the deadline. now.. feedback:
> Already did.
>
> > just to be clear, this won't work for all slow runners. i'm not even
> sure
> > this will help at all since these runners should be checking for this
> catch
> > word and returning immediately if it doesn't exist anyways. what this
> would
> > save is starting them in the thread; i'm not sure that's really a
> > bottleneck.
> You're right. That's not really a bottleneck. But still if the catch-word
> was
> made configurable there is no real reason why a runner that only reacts to
> a
> catch-word should be instanciated an do the logic itself. This can be done
> by
> the manager-class. While this won't have a (noticable) impact on speed it
> would at least mean less work for the runner-programmers.
> I tried to clear that up a bit in my proposal.
>
> > the runner classes will remain part of libplasma. there's no material
> > benefit to having a second library just for this functionality, thought
> > having separate libraries to link against will increase the time to
> > startup.
> Ok. Changed that.
>
> Thanks for your input!
>
> Matej
> _______________________________________________
> Panel-devel mailing list
> Panel-devel at kde.org
> https://mail.kde.org/mailman/listinfo/panel-devel
>



-- 
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/20080331/3d86562a/attachment.html 


More information about the Panel-devel mailing list