[Development] Qt6 source changes

[Giuseppe D'Angelo]

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 | giuseppe.dangelo at kdab.com | 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4007 bytes
Desc: Firma crittografica S/MIME
URL: <http://lists.qt-project.org/pipermail/development/attachments/20181031/6eabfa1f/attachment.bin>