RunnerEngine / runner exec splitting

[Jordi Polo]

I completely see your point: having strongly coupled interfaces is hard to
maintain and maybe nonsense in this case.

I've thought a bunch of possible commands (just as an example), where I put
X means one word. Some are already implemented or possible, others don't,
others only should be available for some data, other if some app is running
and other are general.
Please don't take them too seriusly, just to let us know what kind of
attributes the commands can have.

define X
de2en X ,  en2es X
calc or =
translate de2en X   <- needed if the above only cares about words
rotate X Y (X being how much rotate it and Y the an image file)
map X (get a map)
execute 'X'  (the same that simply X, executes a command)
terminal 'X' (the same than above but on Konsole)
read later X (add to a TODO plasmoid)
install X (over a .deb or .rpm in a webpage link or file)
install amarok script X (in kde-apps.org ... )
Add to bookmark X
delete from bookmark X
syncronize with del.ici.ous X
delete X
comment X (add metainfo to file)
Lyrics X
Add to play list X
Play X
next song (global command, X not needed)

As you said, the X can come from the user input or from the clipboard
selection. We don't care. So all the commands with X can be efectively
executed over desktop objects. Mainly files but there are a couples of
examples with links.

I also think that at least one modifiers to the commands can be very useful
(don't know how to add it to the language) : "insert info" (get the
map/lyrics etc. On a window or insert that info  in the current widget?) .

I think that the above examples give a good insight about what information
we'll need to effectively match actions and objects:

- We need to know what kind of object can X be (rotate will not apply to
links for example).
- We need to know what running application this action rely on (add to
playlist, next song)
- The rating of commands relative to others.
- Of course we need to know the text (command) the user will use to execute
the action.


For the first requisite, we have mimetypes, but we don't have anything that
indicates general entities of an desktop. I argue that having that
information on advance will make the runners trivial for some situations (so
simple they can be defined in .desktop files) and will effectively allow to
share the results of the parsing between runners.
So the parsing comes before runners and the result can be left in the .type
passed to the runners. In fact, this is not anything radical from the
current approach.

So what about this approach:

Move parsing up. Parsing will be done in SearchContext::determineType with
plugins. When I am saying parsing I mean determine the type, commands will
not be parsed here, only entities (bookmark, contact, etc)

The RunnerManager will use the type, the mimetype, the apps running, any
limit imposed by applications (only numerical, etc). To determine what
runners are applicable and show them. The RunnerManager also knows the
ranking of the runners and it is a good place to put any learning (show most
used first ...)

As you said a command mode is not the preferred way, so we can just have
commands at the same time. When the user types a command (read later for
instance), it will be passed with the type "UnknownType". It is work of
RunnerManager to thanks to other information (apps running) compare with
available commands and act in consecuence.

I think this approach is more reliable and controllable than the
postprocessing idea.
With this approach the coupling between interfaces has being only augmented
with the type information. I think it can not be considered a tight
integration (not much more than just giving the mimetype).


To finish, a tentative .desktop file (or the c++ runners) definition should
have this information:

Name
Type
Icon
Applications needed
ObjectType
Mimetype
Rating
Command
Exec
Even if .desktop files prove not being powerfull enough, this info should be
provided by C++ runners to the RunnerManager.

The big problem I see with this approach right now is that the commanding
language will become mainly "verb noun". Being verb the command and noun the
object.

Other possible problem you spotted is that we have more plugins (code) to
write. I think that the parsers will be relatively few. And write the parser
to let the contents on the type is no more difficult than give hints to
other runners (postprocessing idea).

Please, let me read your comments.

PS:
Example

File 1:
Name=Next  amarok song
Type=command
Icon=...
Rating=
Applications needed=Amarok
Command=next song
Exec= dbus ... #call to amarok to skip to next song

File 2:
Name=Next  juk song
Type=command
Icon=...
Rating=
Applications needed=Juk
Command=next song
Exec= dbus ... #call to juk to skip to next song

The RunnerManager will have 2 runners providing the same command. It will
select the one applicable (if only one Amarok or Juk is running) or will
choose the one with better rating if both are running (hell, why!)


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

> 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
>
> _______________________________________________
> Panel-devel mailing list
> Panel-devel at kde.org
> https://mail.kde.org/mailman/listinfo/panel-devel
>
>


-- 
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/20080327/d0cc37b2/attachment-0001.html