Hi, Il 31/10/18 11:19, Иван Комиссаров ha scritto:
1) QAbstractItemModel. I want to introduce change that adds QModelIndex parameter to headerData(). For now, QHeaderView ignores the rootIndex() property which prevents creating models with sub tables in each index (only tree models are supported now). The example - you need to display a struct (or, protobuf message) as a table. Each struct can have sub structs (or, arrays of structs) so the tree is not enough to display it. I wrote a working prototype back in 2015 which required subclassing QAIM and copying the whole QHeaderView into the project. In this case source compatibility can be saved by having 2 virtual headerData methods, the one without modelIndex market deprecated.
This is reasonable given the tree-of-tables that QAbstractItemModel models; there's the bigger question of whether the one-API-fits-all is a good way forward, however I don't see anyone willing to rewrite the model classes for this. (There are also another couple of ideas I have in the QAIM department, e.g. a multiData(), which is just BC because it's a new virtual).
More in general, are the existing views supposed to leverage the nested header data?
And, apart from the issue of taking function overloads, how is this a source incompatible change?
2) QVariantList/QList<QImage> and friends. I would like to to see most of QList usages in Qt eliminated in favor of QVector. I won't repeat Marc's arguments against QList. Instead, I want to ask the other thing - is breaking user code that uses "QList<T> list = someQtApiFunc();" is forbidden too? If Assumption that QVector is API-compatible with QList (which is not true, I suppose, but can be mostly fixed) that should not be a big deal to replace the usages of a QList with "auto list = someQtApiFunc();". Qt should really evolve and stucking with QList for the next 10 years is a bad idea IMO.
This is still an open problem.For starters, I would be against such a massive break for user code. "Auto"-ifying doesn't work as you described, because for many other usages you can't use auto but must name the type (class members, function parameters, pre-C++14 function returns).
If you want to achieve that, it's just simpler to make QList a type alias or a subclass of QVector.
Or leave QList alone, deprecate it, change Qt to return QVectors, and add some implicit conversion.
In other words, I've no idea :) Even then, we need to solve the other problems:1) QStringList/QByteArrayList/etc. having extra functions on top. Keep as is, move them to QVector?
2) There are users relying on QList optimized prepend behaviour. How to support that?
3) There are users relying on QList's integrity of references when in array-of-pointers mode.
(Note: 2+3 aren't "hearsay". Qt itself relies / used to rely on them, e.g. in QPostEventList. I can't imagine in how many other places in Qt a QList is being used relying on this optimization...)
My 2 c, -- Giuseppe D'Angelo | [email protected] | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts
smime.p7s
Description: Firma crittografica S/MIME
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
