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

[Alberto Mardegan]

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 guess these classes are mostly meant to easily expose C++ QAIMs to
QML, but it's not always the case. It would make sense for my
ModelAggregator element to work with string lists as well, and also a
FilterProxyModel which presents a filtered sub-model of a source model
could be expected to work on QML string lists as well...

Ciao,
  Alberto

-- 
http://blog.mardy.it <- geek in un lingua international!