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

[Alan Alpert]

On Fri, Jan 17, 2014 at 7:01 AM, Alberto Mardegan
<mardy at users.sourceforge.net> wrote:
> On 01/15/2014 10:48 PM, Alan Alpert wrote:
>>  This approach could also apply to the original suggestion by Alberto,
>> in the absence of a separate add on module (which Sean couldn't use
>> because of the QtQuick.Controls dependency). Just requires a higher
>> bar for code review/quality, but I'm currently leaning in favor of
>> extra models convenience classes. It's a decent hold over measure
>> since the new model/views have been taking so long.
>
> That's good to know. :-) I've got a question on the implementation side:
> when writing convenience classes which proxy (part of) the contents of a
> source model (or many), is it fine to code the source model type as a
> QAbstractItemModel?
> If so, what will happen if people try to set QML string lists (or lists
> of objects) as source property for the proxy model? Will the QML engine
> do the wrapping into a QAIM, or will this simply not work? If it doesn't
> work, do we care?

I don't think it matters too much, so if it doesn't work then don't
worry about it. But if you want this to work, you can make the source
for the proxy model work like the views (accepts QQmlInstance models
and can turn numbers, lists and QAIMs into a QQmlDelegate model).

QQmlInstanceModel and QQmlDelegate model are private API, but if
you're going to stick it in QtQml.Models that is not a problem.

--
Alan Alpert