Gregory spaketh: > We use QML in a true life, complex application (a desktop email client > with the interface fully done in QML) >
I am *very* interested in this. My QML use is also "heavy desktop". > Over the course of the last few months, we tried a lot of different > setups, until we found what works best for us: > > <snip, good overview of value-semantics model/object wrapping>, > > This setup may seem a little bit complicated, especially the fact that > for each model we actually have two classes (Mail and MailObject, > Contact and ContactObject, etc...), but thanks to some nice macros, > it's quite easy to maintain it. The fact that the models are fully > shared, copy-on-write classes that we can put in QLists or QHashes is > a huge win, in my opinion, and really worth the effort. > > I think I'm going to write a blog post to give more details about this > setup, if anyone is interested. > I'm *very* interested in such a blog post. I've long wanted some kind of QModelIndex type thing with BOTH a (void*,TYPE_ENUM) so I could reference state, and have type information on the state referenced (the Trolls suggest some QModel/QModelIndex work is in progress), to similarly provide value-semantics for models with rich heterogeneous application-specific types. IMHO, this is ever-more-important when bridging to QML (from business logic), due to the dynamic nature of QML, and the "loose parenting" that is implied in QML (for very good reason). BTW, I like your approach, and would like to learn more about it. > (Also, if you want to try it out, you may sign-up for the beta: > http://betterinbox.com - will be ready in a couple of weeks :) > Signed up! I've been looking for a good one for *decades*, and it's about time to put it in a really cool animated environment like is possible with QML! ;-)) --charley
_______________________________________________ Qt-qml mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt-qml
