<br>Ok, I have drawn a diagram in a piece of paper about the proboem, I am dangerous.<br><br>We have this (I may be mistaken):<br><br> text -> krunner -> runners (plugins) , they match and create results -> show to user -> user selects -> exec<br>
<br>We can change to this:<br><br>text -> krunner -> parsers (plugins), they match and create standard data -> runners' manager -> runners (plugin or .desktop) -> create results -> show to user -> user selects -> exec<br>
<br>Three new guys around:<br>- .desktop files able to define results and execution. I think you are right, they can not do everything that will be needed. C++ plugins + being able to use .desktop files should be the best of both worlds.<br>
<br>- standard data. I mean the "types" of desktop entities. This can be defined the same way mimetypes are defined, creating a number of type/subtype. Maybe other squeme is better? Commands will also be standardized. So even if the commands parser is able to manage synonyms "play next" "next song" or user defined "song no more" will send the same command.<br>
<br>- runner's manager. The main guy. It will load all the c++ runners plugins and the .desktop files. It will have a table with the possible types. For each type, it will have a list (ordered honoring priority) of runners.<br>
<br>And one change:<br>
- Runners are splitted in "parsers" and "runners" (same name but don't
mix both). What I now call runners only present data to the user
according to the match and execute it. The parsing is done in the
parsers.<br>
<br>The runners will have a new field to indicate what application they can be used with (default, no application restriction). Optimally, when an application starts or finish, runner's manager will be called so it will not call to runners that need a particular application (this will solve the "next song" problem).<br>
<br>Also, I think it will be easy to implement a MFU(most frecuently used) algorithm inside one type. <br>I am not sure if apps should deactivate/activate runners or parsers.<br><br>The runner's manager is the name of a function, it can be just some classes in krunner. <br>
<br>So, a text enters krunner, it is parser by the plugins. The possibly
multiple data is passed to the manager which for each data calls all
the runners that manage that kind of data and not deactivated. <br><br><br><br><br><div class="gmail_quote">2008/3/26 Aaron J. Seigo <<a href="mailto:aseigo@kde.org">aseigo@kde.org</a>>:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">On Tuesday 25 March 2008, Jordi Polo wrote:<br>
> What I propose is expanding SearchContext::Type (surely will become other<br>
> thing) to make it more generic. We have mimetypes for Files. We can have<br>
> that field to describe desktop entities. Some examples:<br>
><br>
> Type = File<br>
> Mimetype = image/jpg<br>
><br>
> Type = Command/switch<br>
><br>
> Type = Contact/email<br>
><br>
><br>
> So the runners' match method will be almost the same than now but will<br>
> encode in the Type field the result of their parsing.<br>
<br>
</div>this would be per-match, so i'd suggest not re-using SearchContext::Type for<br>
this but introducing a SearchMatch::Type. it would need to have a CustomType<br>
as well, of course, to allow runners to provide their own exec still should<br>
that be desired.<br>
<div class="Ih2E3d"><br>
> To start with, there is a consequence. The exec method of the runners can<br>
> change to a very different kind of beast (go away?). Most "exec" methods<br>
> right now just do simple things ( call to the browser is the most popular<br>
> action).<br>
> So, why can just be defined by a file like the servicemenu of konqueror?<br>
<br>
</div>i'd suggest extending SearchMatch::exec to provide default implementations for<br>
the common types, though these can be augmented with .desktop file basd<br>
actions which would appear as alternative actions ('verbs to the noun')<br>
<div class="Ih2E3d"></div></blockquote><div><br>Why not .desktop as first order citizens just like the plugins?<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d"><br>
> Example:<br>
> [Desktop Entry]<br>
> Type=Command/shutdown<br>
> Actions=byeWorld<br>
><br>
> [Desktop Action byeWorld]<br>
> Name=shutdown<br>
> Icon=system-shutdown<br>
> Exec= dbus #call to kworkspace shutdown<br>
<br>
</div>this is a bad example. it should be done using the library function rather<br>
than dbus.</blockquote><div> </div><div>why? I took the syntax from an example of someone called aseigo :p who used a servicemenu to make a menu to set the desktop background. He used dcop but a library call was available for sure. <br>
The only problem I can think of is performance. But being shutdown ...<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;"><div class="Ih2E3d"><br>
> Of course having the "type" info around gives much more benefits: Actions<br>
> of the clipboard can be converted to this (eventually runners will run on<br>
> the clipboard),<br>
<br>
</div>what would this do, exactly? that sounds something that belongs in<br>
SearchContext, not SearchMatch.<br>
<br>
of course, such a type field isn't extendable by third parties, so would<br>
probably end up being text based rather than an enum? =/</blockquote><div><br>Parsers will say that we are dealing with a protocol/http URL for instance. For http:// in my clipboard I have several browser and send address by email. It can all be done with .desktop files. <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;"><br>
<div class="Ih2E3d"><br>
> context (the application we are using) can be added as<br>
> information making it possible that the services are available only for<br>
> some applications (imagine what services you'll like for a sound type of<br>
> file inside Amarok and how they are different to konqueror).<br>
<br>
</div>what might be cool here is to allow applications to register d-bus interfaces<br>
with SearchMatch invocations, making them naturally only available when the<br>
application is running. so typing "next song" would skip amarok forward if it<br>
was running, or juk forward if it was.<br>
<br>
however, this gets a bit more involved since it implies:<br>
<br>
* allowing runners to be removed from the pool if they require a d-bush<br>
interface and it doesn't exist (well, i suppose they could just always return<br>
null results? would be nice to have a way for a runner to opt in/out of<br>
matching though)<br>
<br>
* standardizing what this d-bus interface(s) would look like</blockquote><div><br>I think that the runner manager can be aware of the applications that are being run to avoid the standarization of that d-bus interface. The commands should be standarized, anyway the interface between parsers and runners should be standarized. <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;"><br>
<div class="Ih2E3d"><br>
> In short:<br>
> Runners can be split between RunnersEngine that makes the parse and builds<br>
> the type and desktop files with the actions.<br>
<br>
</div>i don't think .desktop files would be able to replace all exec() methods.</blockquote><div><br>Yes, you are right, I see it clear now.<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;">
<br>
<div class="Ih2E3d"><br>
> The info that RunnersEngines provide can be used elsewhere.<br>
<br>
</div>they can already, of course. speaking of that, something that we can't know<br>
from runners is which are information and about which domains. so it could be<br>
useful for runners to list in their .desktop files what kinds of matches they<br>
might produce, so apps can construct a query that limits the pool of runners<br>
to a specific use area (e.g. only informational, only numeric calculations,<br>
only ..)</blockquote><div><br>Well, the .desktop files should say what "types" the runner is interested in. I can not envision a user-case for this so I am not sure if I am understanding what you meant. </div></div>
<br>Thanks for your time.<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>