Homerun sources and Plasma runners

[Aurélien Gâteau]

Hi all,

Yesterday afternoon, Aaron, Alex and I discussed Homerun sources, Plasma
runners (and a few other topics). We agreed it would be better to have
Homerun use Runners instead of proposing its own plugin API and
eliminate as much as possible of the forked code.

# Closing the gap between Runners and Sources

I do not have a proper plan to close this gap yet, but I now have more
knowledge about runners and some questions.

A preliminary subject is API compatibility: I don't think it is possible
to extend the current AbstractRunner interface in a BC way to meet our
needs. Would you be ready to create a new runner interface?

This would require:
- Defining and implementing this new interface (let's call it
   AbstractRunner2 for now)
- Implementing an adapter to load old AbstractRunner-based runners
- Porting KRunner to use AbstractRunner2 and the adapter
- Progressively porting runners shipped in KDE SC to AbstractRunner2

Is this approach acceptable for you?

Assuming it is acceptable, I started to put together a list of features
which are specific to each interfaces.

Runners features missing in Sources:
- more information for matches (match type, relevance, subtext...)
- multiple actions per match
- configuration interface per match
- drag'n'drop

Sources features missing in Runners:
- model-based => more QML friendly
- can update matches
- "standardized" favoriteIds
- browsing support (as in: entering/leaving folders, application
   groups...) by invoking the source with named arguments
- future need: reorder items

This list raises more questions:

Q: Do we want the ability to update Runner matches?

I think KRunner could benefit from this because it would make it
possible to asynchronously fetch elements which are time or CPU
intensive to retrieve (example: images on the network)

Q: Do we want the ability to browse in the Runner interface?

Of course I think it is nice to have this, but I can understand it may
not match with the way you think KRunner should work.

# Subject #2: Resolving RunnerModel fork

I thought about the RunnerModel fork issue as well.

If we create an interface which uses a Qt model to expose its items,
this issue will become much easier to solve: we could create a model
which groups all runner output models as a tree, then KRunner could use
a KDescendantsProxyModel [1] on top of it to recreate a flat model, or
just display all elements of the tree unindented.

This assumes we can make QML do what we want with that tree model, which
may not be possible. In that case we can always fallback to what
Homerun::RunnerModel does: a "flat" model with one row per runner, each
runner row exposing a "model" role (Homerun doesn't exactly do that, but
it's close enough)

Thoughts?

Aurélien

[1]  
http://api.kde.org/4.9-api/kdelibs-apidocs/kdeui/html/classKDescendantsProxyModel.html