Homerun sources and Plasma runners

[Aurélien Gâteau]

Le vendredi 16 novembre 2012 18:16:12 Marco Martin a écrit :
> > 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?

It makes it possible to expose existing models: for example the model of the 
current Places is a proxy model on the existing KFilePlacesModel.

It also brings for free robust support for addition, update and removal 
results without having to implement this again in RunnerManager.

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

I don't want this either :)

I haven't investigated how to use mimedata yet. Homerun needs to be able to 
tell if an item is an url, an application, something else so that it knows if 
it can be favorited and in which favorite "category" it should go. If mimedata 
provides this, that's fine.

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

I was referring there to allowing the user to reorder items. This is going to 
be needed to let the user reorder its list of favorite apps/places.

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

Thinking a bit more about it, what Homerun needs is to know if a result can be 
dived into instead of opened with an application. I think this does not 
necessarily means KRunner behavior must change: as long as the information is 
there, Homerun and KRunner can use it differently.

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

I am not fond of tree models in the Qt sense of tree models since, as you 
know, they are painful to use in QML. I'd rather have a model which exposes 
runner submodels for its rows (but those submodels would not have any 
submodels themselves).

Aurélien