[Development] thoughts about a shared models module, and models in general (was Re: Would a (QML) model aggregator class a welcome addition?)

[Juergen Bocklage-Ryannel]

On 15.01.14 09:48, Rutledge Shawn wrote:
> On 10 Dec 2013, at 11:43 PM, Alan Alpert wrote:
>
>> 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!)?
>
I also like the idea. I would also like to see a qml-extra or 
qml-contrib repo. Which acts more like a package manager and a 
standardized way to fetch/compile/install a package from there. These 
packages (e.g. qml plugins) should have a common module prefix (e.g. 
com.qtproject.contrib.<category>.<module>). Which packages will be 
hosted there is up to the individual contributors (or a maintainer) to 
decide. These packages should ideally not be depending on each other 
only on Qt5.

If a package is good enough the qt-project could have the option to add 
it into their core-module (e.g. a promotion) and take ownership of it, 
if this is wanted at all.

I'm thinking the way nodejs works with the npm package manager. It's so 
easy to search packages and install them as local or global packages 
(npm install express). Similar exists for HTML packages 
(http://bower.io/ or even a more extended version http://yeoman.io/, 
which includes a generators).

Just thinking aloud:-)

/ juergen