Introducing Homerun

[Aurélien Gâteau]

Le dimanche 11 novembre 2012 12:02:58 Aaron J. Seigo a écrit :
> On Friday, November 9, 2012 23:09:35 Aurélien Gâteau wrote:
> > As you can see, it is a fullscreen launcher with content organized in
> > tabs.
> 
> i find it to be a very interesting approach, and one that imho has
> potential.
> 
> there are a number of visual issues right now and a few usability ones. if
> you could let us know what sort of feedback would be helpful to you, or
> alternatively when such feedback would be useful, i'd be happy to write
> more on this ...

We are happy to receive any feedback on both appearance and ergonomics. I know 
some parts of Homerun definitely need more work, the configure editor for 
example is quite clunky: the goal was to have something feature-complete, but 
it is painful to use right now.

> i think with some additional work, this could make a useful replacement for
> kickoff in a future release.

Nice!

> i'm a little sad that the early work of making a QML SaL has been lost,
> however. that seems like a bit of a lost opportunity. is there any earlier
> work on this goal that can be salvaged, or did the objectives get changed
> almost instantly from the beginning?

The original kde-workspace branch is still available on plasma/sreich/sal-qml.
When I joined the project I was told the goal was to make an alternative 
launcher rather than a 1:1 port of SaL.

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

If we can find a way to do everything a Source can do with a Runner, I am happy 
to drop the Source API. There are other features which I think are not 
available for Runners right now. But I'd be happy to be proven wrong:

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

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

* Browsable models
If you list the content of a dir, clicking on a dir item will cause the source 
model to emit an "openSourceRequested" signal, which causes Homerun to ask the 
relevant source for a source model with parameters to list the content of this 
subdir. Sources can change while browsing: for example clicking a place of the 
FavoritePlaces source, causes the Dir source to be opened, showing the content 
of this place.

Furthermore, the source model can expose a PathModel to represent the current 
position in the hierarchy tree.

* Submodel models
A source model can either expose a list of items, or expose a list of 
submodels, which themselves expose a list of items. This makes it possible for 
a source model to expose a categorized list of items. The Runner source uses 
this to group Runner results by Runner, the AllInstalledApps source uses this 
to list all installed applications, grouped by their first-level category 
(Multimedia, Office, Games...)

I think that's it.

Aurélien