Homerun sources and Plasma runners

[Marco Martin]

On Friday 16 November 2012, Aurélien Gâteau wrote:
> 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?

we should first see if it *really* needs to be binary incompatible,
then, if it is, to see if it *really* needs to be source incompatible

last resorts... last ;)

> 
> Sources features missing in Runners:
> - model-based => more QML friendly

I still think that wrapped in a model or not is a detail.
still don't see what advantages would bring the api being a model, rather a 
model being a client?

> - can update matches
> - "standardized" favoriteIds

what would have more than mimedata?
(would still not require all runners to be bookmarkable, don't really want to 
have a bookmark of the result of the query "1+1=")

> - browsing support (as in: entering/leaving folders, application
>    groups...) by invoking the source with named arguments
> - future need: reorder items

the model should reorer as needed when results either change their priority or 
a new one arrives in between

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

probably, it makes sense, yeah. (a new match arriving with the same id would 
probably fit the bill, is then responsibility of the model to update the match 
with that id

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

hmm, basically a resultthat opens in a list of items? i can see a can of worms 
here...

maybe a result being able to launch another query...
and anyways never, ever more than one level deep.

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

for how qml models work, i don't see any other solution than a model per 
category.
that's how tree models are "supported" with visualdatamodel

having a tree model doesn't save you much in term of overhead compared to a 
proxy model per category, in the end to display that data you will still end 
up with a proxy per tree branch.


Cheers,
Marco Martin