[Development] Would a (QML) model aggregator class a welcome addition?

Alan Alpert 416365416c at gmail.com
Tue Dec 10 23:43:13 CET 2013

On Tue, Dec 10, 2013 at 12:32 PM, Alberto Mardegan
<mardy at users.sourceforge.net> wrote:
> Hi all!
>   For one of my projects, I found the need to merge several models into
> a single model. I wrote a class for it, and I think it's generic enough
> to be useful for other people, and I wonder if it could be put into Qt
> itself:
> https://gitlab.com/mardy/mappero/blob/directions/lib/Mappero/model-aggregator.h
> Note that the thing is not complete (especially the implementation),
> it's just in a state where I can use it in my application; it needs a
> bit of more work before being ready for the generic use.
> I'm wondering if I should make this extra effort or not. :-)
> If the answer is yes, should it be added to QtCore or QtDeclarative?
> Right now it's using QQmlListProperty so that the source models can be
> declared inline,
> ModelAggregator {
>     Model1 { ... }
>     Model2 { ... }
>     ...
> }
> but that could be removed and substituted by a simple QList of models if
> desired.

This doesn't sound core enough to really benefit from going into
QtDeclarative (please stop developing for QtQuick 1 :P ; but I know
you meant qtdeclarative the repo) or QtCore (no QML types can go into
QtCore, because QtCore cannot depend on QtQml).

Maybe we should have an add-on repository like qt-qml-extras which
contains small but useful QML modules. Candidate content being this
model aggregator, Qt.labs.folderlistmodel, (and I have a couple
imports at home that I could clean up and contribute too) maybe even
QtQuick.XmlListModel or Qt.GraphicalEffects?  Some of the add-on level
imports, like Qt.GraphicalEffects, are large enough for their own
repo. And some, like QtQuick.XmlListModel, feel "core" enough to go in
qtdeclarative as an essential. But there's scope for a lot of small
but useful QML modules, like ModelAggregator and
Qt.labs.folderlistmodel, where a shared and non-essential repository
would make more sense. The alternative is telling each of these little
modules to get their own github/gitorious/playground repo and then
we'd have to organize them with something like inqlude...

Anyone else want a qml-extras repository for collecting small QML imports?

And should it be qt-labs, playground, or qt (add on, not essential!)?

Alan Alpert

More information about the Development mailing list