RunnerEngine / runner exec splitting

Aaron J. Seigo aseigo at kde.org
Tue Mar 25 22:02:01 CET 2008


On Tuesday 25 March 2008, Jordi Polo wrote:
> We have this (I may be mistaken):
>
>   text -> krunner -> runners (plugins) , they match and create results ->
> show to user -> user selects -> exec

correct

> 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

the part i'm not really sure about is whether there's a meaningful distinction 
between parsing and executing. which is to say, both are domain bound and 
both require some shared knowledge (what the parsing maps to is directly 
related to how it gets executed).

while there can be some standardization provided for common execution patterns 
(e.g. browser, krun, ..), much as we do for trader queries in AbstractRunner, 
and allow for servicemenu style .desktop files, there's still quite a close 
mapping between parsing and executing.

my concern is that by splitting them up not only do we end up making more 
plugins someone needs to write (and understand how to write) to make 
something simple, but we increase the number of data interfaces which tends 
to increase the overall fragility.

therefore, i really think that splitting parsing and execution is a bad idea.

that said ... we have often talked about being able to post-process other 
runner's output. what might be interesting is to allow runners to publish 
into the SearchContext parsing hints or results. this would require a 
standard way of describing the parse results, but the upside to this would 
be:

a) parsing can be shared between plugins
b) there's still just one plugin needed for a full parse/execute round trip

but before any of that happens, real concrete use cases need to be drafted up 
in the form of "user enters the following text: __________, runner _________ 
identifies it as __________, user selects that match, runner does _________"

then we can map those to the existing set up and discover exactly what kinds 
of use cases are not covered.

anything else is very hand wavey and we should be very concerned about making 
the interfaces more complex.

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

i'm fine with that...

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

what's the benefit of doing this outside of a runner versus inside of it? 
SearchMatch is currently the atom of a command; what is the benefit of adding 
another abstraction on top of SearchMatch that represents the command that 
SearchMatch will provide?

we do this internally within runners already, but i do not see the point of it 
happening externally. if the concern is providing a single parser syntax that 
is shared, we can create a parser that becomes part of the SearchContext that 
runners can then access. this is the pattern we use with 
SearchContext::type(), for instance... but it is still up to the runners 
themselves to decide what that means (== 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.

yes, this should be a high priority item.

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

this is the part i'm still doubtful about.

> I am not sure if apps should deactivate/activate runners  or parsers.

they already do: plasma triggers a deactivation of all runners except for the 
session runner for user switching.

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

the runner manager needs to move to libplasma where it can be used by other 
components/apps.

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

because they don't know how to parse. really, look at the use cases and it 
becomes very apparent that parsing and execution are the two pieces required 
to make anything real happen and that parsing and execution are *strongly* 
coupled semantically.

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

yes, to set the desktop background, not to shutdown. libkworspace provides the 
canonical reference for this and should be used whenever possible.

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

yes, i understand that. there's no need to add .desktop files to this. we have 
standardized facilities already in kde libraries to launch the preferred 
browser, to open an email client, etc. those aren't the interesting cases and 
are much more easily provided for in AbstractRunner::exec anyways.

the interesting use cases are things like "jump to the next song in amarok" 
or "add a timeline widget to my desktop" ... i don't see those being aided at 
all by .desktop files because:

* they require adding new vocabulary to the parsing
* the new vocabulary matches tightly with the execution

now, one *could* put some string matching (RE's?) in the .desktop file as 
well ... but at that point you may as well have a runner that lets the user 
enter little bits of scripting (using QScript and/or kross?) to do matching 
and what not. in fact, we already have that.

i just don't see the benefit of extending the *parsing* with .desktop files, 
and i don't see how .desktop files would prevent coding in the interesting 
use cases.

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

the standardization of the d-bus interface provided is required to allow the 
calls to be made reliably. these calls can happen in one of two places:

a) AbstractRunner::exec(..) by calling a method via d-bus and passing in the 
data() associated with the SearchMatch.

b) in the runner itself, in which case if it is meant to be used with more 
than one app, all the apps need to expose the same interface

> should be standarized, anyway the interface between parsers and runners
> should be standarized.

which is exactly why it's of very little value to try and separate parsers and 
runners. it just ups the maintenance cost and the couplings will be very 
tight. only if the coupling can be loose is it worth doing. otherwise in 
practice we'll just end up with parser/runner pairs for each runner we 
currently have because the coupling cost will be to high to do otherwise. 
iow, it will make the interface more complex for no real world wins.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Trolltech
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/panel-devel/attachments/20080325/8dbb6e47/attachment.pgp 


More information about the Panel-devel mailing list