[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-panel-devel
Subject: Re: Idea for SoC propsal
From: "Jordi Polo" <mumismo () gmail ! com>
Date: 2008-03-31 1:02:42
Message-ID: a4162420803301802j1135edf7n827a3584cf95a235 () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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@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@kde.org
> https://mail.kde.org/mailman/listinfo/panel-devel
>
--
Jordi Polo Carres
NLP laboratory - NAIST
http://www.bahasara.org
[Attachment #5 (text/html)]
<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>
_______________________________________________
Panel-devel mailing list
Panel-devel@kde.org
https://mail.kde.org/mailman/listinfo/panel-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic