I'm not sure I like it. Maybe it's better to expose more of the individual models in the plugin so you can instanciate them directly?

In D4792#90384, @hein wrote:

I'm not sure I like it. Maybe it's better to expose more of the individual models in the plugin so you can instanciate them directly?

Well, you can already use most of the indivdiual models, for example the recently used documents and apps by using Kicker.RecentUsageModel {}. This is more a convenient access to have the same structure as for main model, which simplifies the QML part.

For example in my case: I want to show the list of program categories, which switches to a list "Recent Applications, Recent Documents" on user request. Using RecentUsageModel is difficult in this case, because it doesn't have group entrys like the RootModel. The best way would be of course to make the RootModel as a somewhat abstract class at the top and let the developer using Kicker interfaces decide which submodels (AppsModel with/without categories, RecentUsageModel Docs/Apps, ...) he wants to add by setting the QML properties (for most of the submodels it's already working this way).

I totally get your argument, but this two-steps-forward-one-step-back code is still so ugly - we need some sort of new approach to composability here. It's more work but may lead us into a better direction long-term.

QML like this would be nice:

FooModel {
  id: foomodel
  RecentUsageModel {}
  RecentAppsModel {}
}

View {
  model: foomodel
}

I.e. be able to define your own menu structure in QML by writing a model that adds child objects to its own entry list.