I completely support Matthias' proposal for an internal "variant" type thing for QModelIndex. My use case is different, but my solution was the same as what Matthias implemented: Generate a "permanant tree" of utility instances (handles) that reference the "real" stuff in the model, because QModelIndex cannot resolve the type of object it references. (This intermediate tree is difficult to maintain/synchronize with model changes, and should be completely unnecessary.)
I understand the issues regarding performance and the current trivial constructor/copy-constructor for QModelIndex, so I can "settle" for an *additional* int-or-enum value (in addition to the current void* inside the QModelIndex). Our use case, very painful: Applications commonly use "native" models of heterogeneous types, and we need to create QModelIndex references to those model "nodes". With the current "void*", we do not know the *type* to which it points. So, we create an "adapter utility" instance that *does* know the type. Unfortunately, these "adapter utility" instances come-and-go like the QModelIndex comes-and-goes, and the current Qt MVC design provides no possible mechanism to delete these "adapter utility" instances. We need value semantics inside the QModelIndex itself, or the ability to inspect the "void*" from the QModelIndex to know *what type* it references. (Because there is no possible mechanism for value semantics for these "adapter utility" instances, we have a permanently maintained "utility instance tree" that mirrors the *real* model, just as did Matthias.) This is my *only* serious problem with the Qt model/view infrastructure, and it is a (very) big problem. Previous discussion at: < http://lists.qt.nokia.com/pipermail/qt5-feedback/2011-May/000047.html> --charley
_______________________________________________ Qt5-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
