<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
Anyway, I went through both your proposal and Matej's a few mins ago<br>
and I'll provide feedback soon. I noticed your latest draft is quite<br>
different from the first one you posted and as of now it conflicts<br>
with mine :-S (the first one didn't). </blockquote><div><br>I am not sure if you are talking with me. Anyway, if you are going to make any work in krunner, I am interested in talk with you. If 3 of us are going to work on krunner, we'll need quite a bit of talking. I wait your comments. Also, I use to be in #plasma and #kde-devel, my nick is surprisingly jordi.<br>
<br><br>And in a someone unrelated comment, as expected, multilingualism is a difficult goal. I've been playing with some ideas in the calculator runner (this runner may be the most difficult one in term of syntax, that's why I started testing ideas there).<br>
<br>Right now the CalculatorRunner will run the text input as qscript code. What make it very simple but confuses users who generally expect some more user oriented math language (programming languages make its decisions on syntax knowing they will be used by programmers).<br>
<br>I've tried to write a small parser. Even working for simple cases it gets crazy easily ( math expresions can be intrincate ...) <br><br>And of course multilinguism is a problem even in a "restricted" domain as maths. In spanish we don't use "sin 30" but "sen 30". I also wanted to implement the google command "X% of Y", which is easy but Japanese will find it really awkward (I don 't think they can get used to it) because they say "YnoX%". <br>
<br>So the only solution is go to a pure mathematical usage (I'll send a patch when ready). <br>The mathematical language has evolved to become universal at least for signs, operant positions and the like. If someone knows exceptions on this, please tell me.<br>
The "sen" example of spanish is considered an alternative to "sin" (though I'm spanish and I didn't know about "sen" not being the standard Spanish name). <br><br>Summary: Defining the language beforehand is a much better idea although less flexible than letting the task to each application.<br>
<br><br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Anyway, I like what you're<br>
proposing. Intelligence in a launcher program is something I wanted to<br>
implement. I tried a limited version back in my fork of Katapult but<br>
focused on multithreading and the infrastructure for KRunner last<br>
year. But I like what I see so far. :)<br>
<br>
Ryan<br>
<br>
2008/3/31 Jordi Polo <<a href="mailto:mumismo@gmail.com">mumismo@gmail.com</a>>:<br>
<div><div></div><div class="Wj3C7c">><br>
> Your proposal has striking similarities to mine:<br>
> <a href="http://www.bahasara.org/raw-attachment/wiki/Papers/gsoc.txt" target="_blank">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<br>
> interested in the performance of the future krunner and I am more interested<br>
> 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<br>
> see discovering the type of information or other text manipulation task as<br>
> more consuming than ranking. Keep track of most used runners, add<br>
> blacklisting and priority and rank according to that should not take a lot<br>
> 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<br>
> and their syntax.<br>
><br>
><br>
> 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>
><br>
> > Am Sonntag, 30. März 2008 21:48:58 schrieb Aaron J. Seigo:<br>
> ><br>
> > > please be sure to file this soon enough on<br>
> <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>
> > Already did.<br>
> ><br>
> ><br>
> > > just to be clear, this won't work for all slow runners. i'm not even<br>
> sure<br>
> > > this will help at all since these runners should be checking for this<br>
> catch<br>
> > > word and returning immediately if it doesn't exist anyways. what this<br>
> would<br>
> > > save is starting them in the thread; i'm not sure that's really a<br>
> > > bottleneck.<br>
> > You're right. That's not really a bottleneck. But still if the catch-word<br>
> was<br>
> > made configurable there is no real reason why a runner that only reacts to<br>
> a<br>
> > catch-word should be instanciated an do the logic itself. This can be done<br>
> 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>
> ><br>
> ><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>
> > Ok. Changed that.<br>
> ><br>
> > Thanks for your input!<br>
> ><br>
> > Matej<br>
> ><br>
> ><br>
> ><br>
> > _______________________________________________<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>
> ><br>
><br>
><br>
><br>
> --<br>
> Jordi Polo Carres<br>
> NLP laboratory - NAIST<br>
> <a href="http://www.bahasara.org" target="_blank">http://www.bahasara.org</a><br>
><br>
> _______________________________________________<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>
><br>
><br>
_______________________________________________<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>