Introducing Homerun

[Aurélien Gâteau]

Le mercredi 14 novembre 2012 12:33:55 Aaron J. Seigo a écrit :
> On Wednesday, November 14, 2012 11:30:58 Aurélien Gâteau wrote:
> > Le mardi 13 novembre 2012 11:23:00 Aaron J. Seigo a écrit :
> > > 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).
> 
> if you need to be able to group by runners, add that to the existing
> implementation. how does the model in homerun facilitate grouping by runner?

In a scary way... you know how QML is not really handy to deal with tree 
models: Homerun RunnerModel groups results by runner by exposing each group of 
runners as a submodel. Probably not the most elegant approach, definitely not 
something I would like to publish in a stable API like libplasma.

> > > > * 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.
> 
> how is this accomplished in homerun?

For most Homerun sources: by exposing the favoriteId role, which follows the 
format described in libhomerun doc (which you can build it with "make dox").
For the Runner source: we have code for the "services" and "locations" runners 
which extract information from QueryMatch::data() and returns a favoriteId 
role.

> btw, i just spent some time looking through the homerun source code to see
> how things are put together. it would be super duper helpful if you would
> actually share how things are done in the code. in my email i provided
> things like dbus calls, method names .. things that are useful as starting
> points should one want to look into the code.

You can start with devdoc/overview.md, but that document needs to be 
completed. libhomerun doc can be interesting as well, even if it's about 
writing sources, not about the internals of Homerun.
Can you be more specific about which parts you are interested in?

> > This system is also used to browse installed applications for example.
> 
> .. for which we also have pre-existing models.

Sure, I was just pointing out this was not file-only.

Aurélien