Thanks, Alan -- very rich email that helps me think about declarative-model-instance-handling.
Alan spaketh: <snip, "What is QML declarative-best-practice for models?"> > Reusable components/delegates, where data propagates in one direction, is > the > best-practices pattern that obviates this need. <snip>, > For list delegates, this is managed through the model. Individual delegates > should only depend on the model for state and interaction. If that's not > enough you probably need a custom view, because views are supposed to > handle > the majority of the UI logic of the data.[1] > <snip>, > [1] A future research topic that I'm keen on, one of these days, is to > better > componetize the Model/View split. QML has very simplified models, but the > Views > are immense and in some ways restrictive. Sometime people just use a > Repeater/Column/Flickable for flexibility, but that's not viable for large > data > sets. There's clearly a better split which would allow for more of the > View to > be written in QML, like the UI logic, while not forcing such large > tradeoffs. > After the successful completion of that research project, suggesting that > you > create your own view would just mean another QML file in your project. > I'm very interested in that future-research-topic (we can discuss offline in the future when you have time), IMHO some work here is needed. For example, consider a large/rich model of a "file-system" where you want rich view(s) of *all* dirs-and-files. Example visualizers might be like: http://lifehacker.com/219058/geek-to-live--visualize-your-hard-drive-usage The dynamic/animated nature of QML seems like a QML implementation (with-or-without-C++) could be gorgeous/rich/useful. If your efforts provided specific insight and guidance to applications like that, it would be ever-so-super-spiffy! ;-) --charley
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
