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 _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
