RunnerEngine / runner exec splitting

[Jordi Polo]

Ok, I have drawn a diagram in a piece of paper about the proboem, I am
dangerous.

We have this (I may be mistaken):

  text -> krunner -> runners (plugins) , they match and create results ->
show to user -> user selects -> exec

We can change to this:

text -> krunner -> parsers (plugins), they match and create standard data ->
runners' manager -> runners (plugin or .desktop) -> create results -> show
to user -> user selects -> exec

Three new guys around:
- .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.

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

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

And one change:
- 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.

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

Also, I think it will be easy to implement a MFU(most frecuently used)
algorithm inside one type.
I am not sure if apps should deactivate/activate runners  or parsers.

The runner's manager is the name of a  function, it can be just some classes
in krunner.

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.




2008/3/26 Aaron J. Seigo <aseigo at kde.org>:

> On Tuesday 25 March 2008, Jordi Polo wrote:
> > What I propose is expanding SearchContext::Type  (surely will become
> other
> > thing) to make it more generic. We have mimetypes for Files. We can have
> > that field to describe desktop entities. Some examples:
> >
> > Type = File
> > Mimetype = image/jpg
> >
> > Type = Command/switch
> >
> > Type = Contact/email
> >
> >
> > So the runners' match method will be almost the same than now but will
> > encode in the Type field the result of their parsing.
>
> this would be per-match, so i'd suggest not re-using SearchContext::Type
> for
> this but introducing a SearchMatch::Type. it would need to have a
> CustomType
> as well, of course, to allow runners to provide their own exec still
> should
> that be desired.
>
> > To start with, there is a consequence. The exec method of the runners
> can
> > change to a very different kind of beast (go away?). Most "exec" methods
> > right now just do simple things ( call to the browser is the most
> popular
> > action).
> > So, why can just be defined by a file like the servicemenu of konqueror?
>
> i'd suggest extending SearchMatch::exec to provide default implementations
> for
> the common types, though these can be augmented with .desktop file basd
> actions which would appear as alternative actions ('verbs to the noun')
>

Why not .desktop as first order citizens just like the plugins?


>
> > Example:
> > [Desktop Entry]
> > Type=Command/shutdown
> > Actions=byeWorld
> >
> > [Desktop Action byeWorld]
> > Name=shutdown
> > Icon=system-shutdown
> > Exec= dbus #call to kworkspace shutdown
>
> this is a bad example. it should be done using the library function rather
> than dbus.


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.
The only problem I can think of is performance. But being shutdown ...


> > Of course having the "type" info around gives much more benefits:
> Actions
> > of the clipboard can be converted to this (eventually runners will run
> on
> > the clipboard),
>
> what would this do, exactly? that sounds something that belongs in
> SearchContext, not SearchMatch.
>
> of course, such a type field isn't extendable by third parties, so would
> probably end up being text based rather than an enum? =/


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.




>
>
> > context (the application we are using) can be added as
> > information making it possible that the services are available only for
> > some applications (imagine what services you'll like for a sound type of
> > file inside Amarok and how they are different to konqueror).
>
> what might be cool here is to allow applications to register d-bus
> interfaces
> with SearchMatch invocations, making them naturally only available when
> the
> application is running. so typing "next song" would skip amarok forward if
> it
> was running, or juk forward if it was.
>
> however, this gets a bit more involved since it implies:
>
> * allowing runners to be removed from the pool if they require a d-bush
> interface and it doesn't exist (well, i suppose they could just always
> return
> null results? would be nice to have a way for a runner to opt in/out of
> matching though)
>
> * standardizing what this d-bus interface(s) would look like


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.




>
>
> > In short:
> > Runners can be split between RunnersEngine that makes the parse and
> builds
> > the type and desktop files with the actions.
>
> i don't think .desktop files would be able to replace all exec() methods.


Yes, you are right, I see it clear now.


>
>
> > The info that RunnersEngines provide can be used elsewhere.
>
> they can already, of course. speaking of that, something that we can't
> know
> from runners is which are information and about which domains. so it could
> be
> useful for runners to list in their .desktop files what kinds of matches
> they
> might produce, so apps can construct a query that limits the pool of
> runners
> to a specific use area (e.g. only informational, only numeric
> calculations,
> only ..)


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.

Thanks for your time.


-- 
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/20080326/a3bc4954/attachment-0001.html