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! _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
