RunnerEngine / runner exec splitting

[Aaron J. Seigo]

On Tuesday 25 March 2008, Jordi Polo wrote:
> What I propose is expanding SearchContext::Type  (surely will become other
> thing) to make it more generic. We have mimetypes for Files. We can have
> that field to describe desktop entities. Some examples:
>
> Type = File
> Mimetype = image/jpg
>
> Type = Command/switch
>
> Type = Contact/email
>
>
> So the runners' match method will be almost the same than now but will
> encode in the Type field the result of their parsing.

this would be per-match, so i'd suggest not re-using SearchContext::Type for 
this but introducing a SearchMatch::Type. it would need to have a CustomType 
as well, of course, to allow runners to provide their own exec still should 
that be desired.

> To start with, there is a consequence. The exec method of the runners can
> change to a very different kind of beast (go away?). Most "exec" methods
> right now just do simple things ( call to the browser is the most popular
> action).
> So, why can just be defined by a file like the servicemenu of konqueror?

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

> Example:
> [Desktop Entry]
> Type=Command/shutdown
> Actions=byeWorld
>
> [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.

> Of course having the "type" info around gives much more benefits: Actions
> of the clipboard can be converted to this (eventually runners will run on
> the clipboard),

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

> context (the application we are using) can be added as 
> information making it possible that the services are available only for
> some applications (imagine what services you'll like for a sound type of
> file inside Amarok and how they are different to konqueror).

what might be cool here is to allow applications to register d-bus interfaces 
with SearchMatch invocations, making them naturally only available when the 
application is running. so typing "next song" would skip amarok forward if it 
was running, or juk forward if it was.

however, this gets a bit more involved since it implies:

* allowing runners to be removed from the pool if they require a d-bush 
interface and it doesn't exist (well, i suppose they could just always return 
null results? would be nice to have a way for a runner to opt in/out of 
matching though)

* standardizing what this d-bus interface(s) would look like

> In short:
> Runners can be split between RunnersEngine that makes the parse and builds
> the type and desktop files with the actions.

i don't think .desktop files would be able to replace all exec() methods.

> The info that RunnersEngines provide can be used elsewhere.

they can already, of course. speaking of that, something that we can't know 
from runners is which are information and about which domains. so it could be 
useful for runners to list in their .desktop files what kinds of matches they 
might produce, so apps can construct a query that limits the pool of runners 
to a specific use area (e.g. only informational, only numeric calculations, 
only ..)

there are some good ideas here, perhaps needs some more design polishing 
though...

-- 
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/3d3e485a/attachment.pgp