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