<br>I completely see your point: having strongly coupled interfaces is hard to maintain and maybe nonsense in this case. <br><br>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. <br>
Please don't take them too seriusly, just to let us know what kind of attributes the commands can have.<br><br>define X<br>de2en X , en2es X <br>calc or = <br>translate de2en X <- needed if the above only cares about words<br>
rotate X Y (X being how much rotate it and Y the an image file)<br>map X (get a map)<br>execute 'X' (the same that simply X, executes a command)<br>terminal 'X' (the same than above but on Konsole)<br>read later X (add to a TODO plasmoid)<br>
install X (over a .deb or .rpm in a webpage link or file)<br>install amarok script X (in <a href="http://kde-apps.org">kde-apps.org</a> ... )<br>Add to bookmark X <br>delete from bookmark X <br>syncronize with del.ici.ous X<br>
delete X<br>comment X (add metainfo to file)<br>Lyrics X<br>Add to play list X<br>Play X<br>next song (global command, X not needed)<br><br>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. <br>
<br>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?) . <br>
<br>I think that the above examples give a good insight about what information we'll need to effectively match actions and objects:<br><br>- We need to know what kind of object can X be (rotate will not apply to links for example). <br>
- We need to know what running application this action rely on (add to playlist, next song)<br>- The rating of commands relative to others.<br>- Of course we need to know the text (command) the user will use to execute the action.<br>
<br><br>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. <br>
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. <br><br>So what about this approach:<br><br>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)<br>
<br>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 ...)<br>
<br>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. <br>
<br>I think this approach is more reliable and controllable than the postprocessing idea. <br>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).<br>
<br><br>To finish, a tentative .desktop file (or the c++ runners) definition should have this information:<br><br>Name<br>Type<br>Icon<br>Applications needed <br>ObjectType<br>Mimetype<br>Rating<br>Command<br>Exec<br>Even if .desktop files prove not being powerfull enough, this info should be provided by C++ runners to the RunnerManager.<br>
<br>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. <br><br>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).<br>
<br>Please, let me read your comments. <br><br>PS: <br>Example <br><br>File 1:<br>
Name=Next amarok song <br>
Type=command<br>
Icon=...<br>Rating=<br>
Applications needed=Amarok<br>Command=next song<br>
Exec= dbus ... #call to amarok to skip to next song<br><br>File 2:<br>
Name=Next juk song <br>
Type=command<br>
Icon=...<br>Rating=<br>
Applications needed=Juk<br>Command=next song<br>
Exec= dbus ... #call to juk to skip to next song<br>
<br>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!)<br>
<br><br><div class="gmail_quote">2008/3/26 Aaron J. Seigo <<a href="mailto:aseigo@kde.org" target="_blank">aseigo@kde.org</a>>:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>On Tuesday 25 March 2008, Jordi Polo wrote:<br>
</div><div>> We have this (I may be mistaken):<br>
><br>
> text -> krunner -> runners (plugins) , they match and create results -><br>
> show to user -> user selects -> exec<br>
<br>
</div>correct<br>
<div><br>
> We can change to this:<br>
><br>
> text -> krunner -> parsers (plugins), they match and create standard data<br>
> -> runners' manager -> runners (plugin or .desktop) -> create results -><br>
> show to user -> user selects -> exec<br>
<br>
</div>the part i'm not really sure about is whether there's a meaningful distinction<br>
between parsing and executing. which is to say, both are domain bound and<br>
both require some shared knowledge (what the parsing maps to is directly<br>
related to how it gets executed).<br>
<br>
while there can be some standardization provided for common execution patterns<br>
(e.g. browser, krun, ..), much as we do for trader queries in AbstractRunner,<br>
and allow for servicemenu style .desktop files, there's still quite a close<br>
mapping between parsing and executing.<br>
<br>
my concern is that by splitting them up not only do we end up making more<br>
plugins someone needs to write (and understand how to write) to make<br>
something simple, but we increase the number of data interfaces which tends<br>
to increase the overall fragility.<br>
<br>
therefore, i really think that splitting parsing and execution is a bad idea.<br>
<br>
that said ... we have often talked about being able to post-process other<br>
runner's output. what might be interesting is to allow runners to publish<br>
into the SearchContext parsing hints or results. this would require a<br>
standard way of describing the parse results, but the upside to this would<br>
be:<br>
<br>
a) parsing can be shared between plugins<br>
b) there's still just one plugin needed for a full parse/execute round trip<br>
<br>
but before any of that happens, real concrete use cases need to be drafted up<br>
in the form of "user enters the following text: __________, runner _________<br>
identifies it as __________, user selects that match, runner does _________"<br>
<br>
then we can map those to the existing set up and discover exactly what kinds<br>
of use cases are not covered.<br>
<br>
anything else is very hand wavey and we should be very concerned about making<br>
the interfaces more complex.<br>
<div><br>
> Three new guys around:<br>
> - .desktop files able to define results and execution. I think you are<br>
> right, they can not do everything that will be needed. C++ plugins + being<br>
> able to use .desktop files should be the best of both worlds.<br>
<br>
</div>i'm fine with that...<br>
<div><br>
> - standard data. I mean the "types" of desktop entities. This can be<br>
> defined the same way mimetypes are defined, creating a number of<br>
> type/subtype. Maybe other squeme is better? Commands will also be<br>
> standardized. So even if the commands parser is able to manage synonyms<br>
> "play next" "next song" or user defined "song no more" will send the same<br>
> command.<br>
<br>
</div>what's the benefit of doing this outside of a runner versus inside of it?<br>
SearchMatch is currently the atom of a command; what is the benefit of adding<br>
another abstraction on top of SearchMatch that represents the command that<br>
SearchMatch will provide?<br>
<br>
we do this internally within runners already, but i do not see the point of it<br>
happening externally. if the concern is providing a single parser syntax that<br>
is shared, we can create a parser that becomes part of the SearchContext that<br>
runners can then access. this is the pattern we use with<br>
SearchContext::type(), for instance... but it is still up to the runners<br>
themselves to decide what that means (== command)<br>
<div><br>
> - runner's manager. The main guy. It will load all the c++ runners plugins<br>
> and the .desktop files. It will have a table with the possible types. For<br>
> each type, it will have a list (ordered honoring priority) of runners.<br>
<br>
</div>yes, this should be a high priority item.<br>
<div><br>
> And one change:<br>
> - Runners are splitted in "parsers" and "runners" (same name but don't mix<br>
> both). What I now call runners only present data to the user according to<br>
> the match and execute it. The parsing is done in the parsers.<br>
<br>
</div>this is the part i'm still doubtful about.<br>
<div><br>
> I am not sure if apps should deactivate/activate runners or parsers.<br>
<br>
</div>they already do: plasma triggers a deactivation of all runners except for the<br>
session runner for user switching.<br>
<div><br>
> The runner's manager is the name of a function, it can be just some<br>
> classes in krunner.<br>
<br>
</div>the runner manager needs to move to libplasma where it can be used by other<br>
components/apps.<br>
<div><br>
> > i'd suggest extending SearchMatch::exec to provide default<br>
> > implementations for<br>
> > the common types, though these can be augmented with .desktop file basd<br>
> > actions which would appear as alternative actions ('verbs to the noun')<br>
><br>
> Why not .desktop as first order citizens just like the plugins?<br>
<br>
</div>because they don't know how to parse. really, look at the use cases and it<br>
becomes very apparent that parsing and execution are the two pieces required<br>
to make anything real happen and that parsing and execution are *strongly*<br>
coupled semantically.<br>
<div><br>
> > > [Desktop Action byeWorld]<br>
> > > Name=shutdown<br>
> > > Icon=system-shutdown<br>
> > > Exec= dbus #call to kworkspace shutdown<br>
> ><br>
> > this is a bad example. it should be done using the library function<br>
> > rather than dbus.<br>
><br>
> why? I took the syntax from an example of someone called aseigo :p who<br>
> used a servicemenu to make a menu to set the desktop background. He used<br>
> dcop but a library call was available for sure.<br>
<br>
</div>yes, to set the desktop background, not to shutdown. libkworspace provides the<br>
canonical reference for this and should be used whenever possible.<br>
<div><br>
> > what would this do, exactly? that sounds something that belongs in<br>
> > SearchContext, not SearchMatch.<br>
> ><br>
> > of course, such a type field isn't extendable by third parties, so would<br>
> > probably end up being text based rather than an enum? =/<br>
><br>
> Parsers will say that we are dealing with a protocol/http URL for instance.<br>
> For http:// in my clipboard I have several browser and send address by<br>
> email. It can all be done with .desktop files.<br>
<br>
</div>yes, i understand that. there's no need to add .desktop files to this. we have<br>
standardized facilities already in kde libraries to launch the preferred<br>
browser, to open an email client, etc. those aren't the interesting cases and<br>
are much more easily provided for in AbstractRunner::exec anyways.<br>
<br>
the interesting use cases are things like "jump to the next song in amarok"<br>
or "add a timeline widget to my desktop" ... i don't see those being aided at<br>
all by .desktop files because:<br>
<br>
* they require adding new vocabulary to the parsing<br>
* the new vocabulary matches tightly with the execution<br>
<br>
now, one *could* put some string matching (RE's?) in the .desktop file as<br>
well ... but at that point you may as well have a runner that lets the user<br>
enter little bits of scripting (using QScript and/or kross?) to do matching<br>
and what not. in fact, we already have that.<br>
<br>
i just don't see the benefit of extending the *parsing* with .desktop files,<br>
and i don't see how .desktop files would prevent coding in the interesting<br>
use cases.<br>
<div><br>
> > * standardizing what this d-bus interface(s) would look like<br>
><br>
> I think that the runner manager can be aware of the applications that are<br>
> being run to avoid the standarization of that d-bus interface. The commands<br>
<br>
</div>the standardization of the d-bus interface provided is required to allow the<br>
calls to be made reliably. these calls can happen in one of two places:<br>
<br>
a) AbstractRunner::exec(..) by calling a method via d-bus and passing in the<br>
data() associated with the SearchMatch.<br>
<br>
b) in the runner itself, in which case if it is meant to be used with more<br>
than one app, all the apps need to expose the same interface<br>
<div><br>
> should be standarized, anyway the interface between parsers and runners<br>
> should be standarized.<br>
<br>
</div>which is exactly why it's of very little value to try and separate parsers and<br>
runners. it just ups the maintenance cost and the couplings will be very<br>
tight. only if the coupling can be loose is it worth doing. otherwise in<br>
practice we'll just end up with parser/runner pairs for each runner we<br>
currently have because the coupling cost will be to high to do otherwise.<br>
iow, it will make the interface more complex for no real world wins.<br>
<div><div></div><div><br>
--<br>
Aaron J. Seigo<br>
humru othro a kohnu se<br>
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43<br>
<br>
KDE core developer sponsored by Trolltech<br>
</div></div><br>_______________________________________________<br>
Panel-devel mailing list<br>
<a href="mailto:Panel-devel@kde.org" target="_blank">Panel-devel@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/panel-devel" target="_blank">https://mail.kde.org/mailman/listinfo/panel-devel</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br>Jordi Polo Carres<br>NLP laboratory - NAIST<br><a href="http://www.bahasara.org" target="_blank">http://www.bahasara.org</a><br>