michael spaketh: > One of the things we're researching now that 4.7 is out the > door is how we work with data sets in QML. Part of that is > researching "next generation" model classes for QML
Outstanding. I *love* your list. In particular, I vote for: (1) Allowing easy creation of custom models (2) Allowing rows to have type information (or any user type information added to the model). I'm a long-time model user. IMHO, the model/view infrastructure is *very* well designed -- that's hard to do, so congrats (people have been attempting general purpose designs in that domain for decades). However, IMHO, the *one* Achilles Heel that I've found relates to QModelIndex: It's a transient on-the-stack type (that's good), but has no type information, so a model with heterogeneous types requires users to create "wrappers" that must be managed in a cached hierarchy that mirrors the "real" model (very expensive). IMHO, this issue will be exasperated in migrating to QML, which IMHO is superior as an interface paradigm, as it increases the chasm between the business logic and the GUI (that's GOOD). My "wish" is that (1) QModelIndex have some context for user type information, OR (2) QModelIndex provide a mechanism for the user to create a "wrapper" that is "owned" by the QModelIndex (so the QModelIndex will delete that wrapper when the index is destructed). There's a thread on this topic from 2006, and we've never really resolved our problems: <http://lists.trolltech.com/qt-interest/2006-11/thread00266-0.html> ----------------------------------------------------- I humbly request something like any one of the follow as changes to QModelIndex, and please include the address to which you want me to send homemade cookies (they will be quite tasty): ANY ONE IS FINE, SOMETHING LIKE: (a) QModelIndex has a function "getFlagShouldDeleteVoidPtr()" so users could re-implement/set state so that the (transient) QModelIndex would "know" to delete the void* resource, which is a QVariant/QWrapper-derived type with extra context the user needed when implementing the model. (b) QModelIndex has (row,col,void*), but would be nice to have (row,col,void*,USER_ENUM) so users could deduce what type is at that location (useful for models with heterogeneous types that do not share a base class) (c) QModelIndex is implemented as a template, like: template<class DERIVED> class QModelIndexBase { ...implementation... }; class QModelIndex : public QModelIndexBase<QModelIndex> { }; // User wants to override something. class MyQModelIndex : public QModelIndexBase<MyQModelIndex> { ...my overrides... }; ... and the "override" is SOLELY for the purposes of (1) triggering "delete" on a wrapper "owned" by the QModelIndex upon destruction of the QModelIndex, or (2) permit user to provide user-type-information. --------------------------------------------------- Or, I could send a cake (if you don't want cookies). Pies are good too. Maybe chocolates (they ship well)? Thanks! --charley _______________________________________________ Qt-qml mailing list Qt-qml@trolltech.com http://lists.trolltech.com/mailman/listinfo/qt-qml
