Introducing Homerun

[Aurélien Gâteau]

Le mardi 13 novembre 2012 11:23:00 Aaron J. Seigo a écrit :
> > > > One of the main differences between Homerun sources and Plasma runners
> > > > is
> > > > that sources can provide default content
> > > 
> > > as can runners (for many releases now). a Runner can define its default
> > > syntax, and that can then be used to get the default content from it by
> > > passing that syntax in to the match method. this is how KRunner shows
> > > content by default when pulling up a specific running in "single runner
> > > mode".
> > 
> > Oh. I was not aware of this. I never ran KRunner in "single runner mode",
> > how does one do it?
> 
> You can see which runners are available for single runner mode with:
> 
> 	qdbus org.kde.krunner /App singleModeAdvertisedRunnerIds
> 
> Then pick one and do:
> 
> 	qdbus org.kde.krunner /App displaySingleRunner bookmarks
> 
> (replace "bookmarks" with the runner of your choice.

Nice, I need to dig more into this.

> > * Models
> > A Runner exposes its results as a QList<Plasma::QueryMatch>. A source
> > model
> > is a Qt model, which is more QML-friendly and can be more efficient to
> > propagate changes.
> krunnermodel, a Qt model that comes with a QML component plugin (so you can
> just import and use it directly) is in kde-runtime/plasma/declarativeimports

I know about this model. We used it in the beginning, I even contributed a bit 
to it. Unfortunately it was not adapted for us because it made it difficult to 
group results by runners.
Also, while it maps the QList<Plasma::QueryMatch> to a model, it does not 
bring full benefit of models from this: KRunnerModel has no way to know if a 
runner added/modified or removed an item so it always has to refresh the whole 
model (minus the hack I contributed to improve this in a certain case).

> > * Favorites
> > Right now Homerun supports two kinds of favorites: favorite applications
> > and favorite places, a source model can use the favoriteId role to make
> > its item "favoritable".
> 
> We've been doing this since the first SAL using QueryMatch::id(). There is
> also RunnerManager::mimeData() which gets you something that is draggable,
> even.

The problem with QueryMatch::id() is that its format is runner-specific. This 
makes sense for KRunner, but not for Homerun because we want to identify 
whether the match is an application or a place so that it can be stored in the 
appropriate favorite collection.

The runner source tries to extract this information from QueryMatches, but it 
only works for the "services" and "locations" runners since it has to 
interpret the value of QueryMatch::data().

> > * Browsable models
> > If you list the content of a dir
> 
> I would stick to the standard directory listing model for this rather than
> invent something new. Search returns from a Runner may return a directory;
> click on that could then be handled using a dir model.

It is not just to list directories: you can browse any kind of hierarchy. This 
system is also used to browse installed applications for example.

> > Furthermore, the source model can expose a PathModel to represent the
> > current position in the hierarchy tree.
> 
> Not sure this at all maps to the idea of search returns; this is more for
> file browsing from what I can see in the UI?

Yes, it is for browsing (not necessarily files).

Aurélien