RunnerEngine / runner exec splitting

[Jordi Polo]

I am going to reply myself to further augment this idea (someone can stop me
please!?)

In the previous email...
Having the type and the mimetype information available makes runners able to
respond to any a several types of entities on the desktop. Files and
directories also. This information can be dynamic, depending on the running
applications, installed applications and "learning" (most used).

Obviously runners can use it and also can use it the actions functionality
of the clipboard (we can have a regular expresion runner, configured as
actions are configured now in the clipboard).

In this mail:
As the system is thought to be used over entities. Why no merge mimetypes
actions inside this?
Every application can have their own particular actions with a given
information + RunnerActions.

We can have this system:

A given software (file view of konqueror or dolphin, the openfile dialog,
etc), have some information selected and the appropiate actions for that
information are requested. The actions are returned and presented to the
user, the user choose one and it is executed.
As it can be seen, it is just the same pattern than my previous mail. The
only thing that changed is that more actions moves from specific
applications to general runners.

Example:

An user right clicks on his /home/user/mycoolcompresseddata.tar.gz in
dolphin filesystem view. The menu appears with a actions submenu, the user
select it. In that moment Dolphin ask for a menu with the available actions
in the system for that given text "/home/user/mycoolcompresseddata.tar.gz"
and hinting the data is for a filemanager type application.
First, the type (File) and mimetype (data/tgz? I don't know) is extracted
from the text and passed to the RunnerManager. The RunnerManager check its
list (an open Ark request adding to volume, a static file request for
decompress, attach to email, etc). of possible runners based on everything I
explained in the previous mail + application hinting.
The RunnerManager can show most usually used options by this user (in a
filemanager type application, thanks to the hinting) first and only show
ExactMatch options.
The data goes back to Dolphin.

If you think, this can bring too many options, you are right, but we have
two old tools to fight that:
- sane defaults : An sane initial configuration
- configurability : Let users modify the rating of actions
- learning : Each desktop will be dynamic, adjusted to the user workflow.


We can have a library of actions on information as now we have a library of
actions on GUI elements.



On Thu, Mar 27, 2008 at 1:58 AM, Jordi Polo <mumismo at gmail.com> wrote:

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



-- 
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/59518d6e/attachment-0001.html