Idea for SoC propsal

[Ryan P. Bitanga]

Hi Everyone,

First of all, welcome Jordi and Matej :) It's nice to see other people
actually interested in KRunner for a change. Now the next time I post
a KRunner e-mail someone other than Aaron will reply. Yipee! Secondly,
hi Aaron, I'm back :) Noticed you made some API changes while I was
busy getting over my ex. ;)

Anyway, I went through both your proposal and Matej's a few mins ago
and I'll provide feedback soon. I noticed your latest draft is quite
different from the first one you posted and as of now it conflicts
with mine :-S (the first one didn't). Anyway, I like what you're
proposing. Intelligence in a launcher program is something I wanted to
implement. I tried a limited version back in my fork of Katapult but
focused on multithreading and the infrastructure for KRunner last
year. But I like what I see so far. :)

Ryan

2008/3/31 Jordi Polo <mumismo at gmail.com>:
>
> 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
>
> _______________________________________________
>  Panel-devel mailing list
>  Panel-devel at kde.org
>  https://mail.kde.org/mailman/listinfo/panel-devel
>
>