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