Introducing Homerun

[Marco Martin]

On Monday 12 November 2012, Aurélien Gâteau wrote:
> 
> 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.
> 

as general ui, it seems to be quite complete and well working already, it 
clearly shows a lot of efforts and attention has been put in it.

as general direction, i share concerns with Nuno, but i think it probably 
serves well some class of users/usecases, since we are seeing many projects 
that are following a similar approach.
personally i think that it may share the problems of some similar interface, 
like the ubuntu lens area or the gnome shell menu.

It's a thing probably excellent for small laptops/netbooks, but that shows two 
problems on larger screens:
* fitts law: the mouse has to travel a very long way between icons (even the 
whole screen in the worst case you need to clock a very far one) either 
decreasing the precision or increasing the required attention to be precise
* information density: there may be several dozens of icons shown at once in 
the screen: when the choice is more than 7-8 objects the brain tends to switch 
from seeing all at a glance to linear scanning.

They seem to give a nod to tablet interfaces, tough without really being one 
(quite proved on how unity works on tablets) risking to be a compromise that 
doesn't really make anybody happy.

however (again, hope not having been sounding harsh in any way) if the amount 
of information at once is limited (by for example making the window a bit 
smaller on larger screens) it may look easier for inexperienced users than 
what we have now (and fix some of the above points).
and anyways, well done qml things can always give good backend, even on a 
really different UI ;)

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

look at the application laucher in polasma active, it's already doing exactly 
that in qml and with a model

> 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
> * Favorites
> * Browsable models
> * Submodel models
the latter two seems just tree models to me? (and yes, tree models are 
supported in qml)

I don't think here is needed a magic one size fits all model.
searching is a completely different mechanism
the model ca easily be switched at runtime.
we already have a model for runners in qml bindings, one for filesystems still 
quite rough, and things for menu/favorites could be handy.

i'm just a bit concerned at reinventing things ;)


Cheers,
Marco Martin