[Development] How to fix TableView's API break?

[Giuseppe D'Angelo]

Hi,

Between 6.3 and 6.4 there's been an API break in QtQuick's TreeView: its 
modelIndex(row,column) function got moved into its base class 
(TableView), and the arguments swapped for it, so now it's 
TableView::modelIndex(column,row).

This is of course an API break, and needs to be fixed.


On the other hand: TableView already has other functions that take 
(column,row), so swapping arguments for modelIndex would create an 
inconsistency. For instance:

> Item itemAtCell(int column, int row)

> positionViewAtCell(int column, int row, PositionMode mode, point offset, rect subRect)

To me this is quite weird. This must be the *only* place in Qt 
model/view APIs where (column,row) is used instead of (row,column), and 
I don't seem to find any justification for this.

Does anyone know?


---

What's more: there's inconsistencies already all over the place in 
TableView! For instance positional functions take (x,y), and not (y,x):

> point cellAtPosition(real x, real y, bool includeSpacing)


Also the above functions are also inconsistently (and weirdly) 
overloaded with overloads taking `point` (== QPointF). For instance:


> QModelIndex modelIndex(point cell)

> positionViewAtCell(point cell, PositionMode mode, point offset, rect subRect)

Here `cell` is a logical index (so why do they take a FP-based point?), 
and for extra fun, cell.x is the *column* and cell.y is the *row* (!!!).


And finally:

> point cellAtPosition(point position, bool includeSpacing)

This is pure evil, as `position` is a position in pixels (relative to 
the TableView's content item), while the return is ... a logical index 
(with again `x` being the column and `y` and the row). The type of the 
parameter and the return value is the same, yet they represent 
completely different things! How is this good API?


---

So, how to fix the above? One could easily fix the API break, but one is 
left with broken APIs all over the place. There's no straightforward 
deprecation mechanism for QML either, and we've dropped versioned includes.

Should one concoct TableViewV2 and TreeViewV2 to fix all the above 
shortcomings? If so, can we have an exception to the feature freeze?



Thanks,

-- 
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: 4244 bytes
Desc: Firma crittografica S/MIME
URL: <http://lists.qt-project.org/pipermail/development/attachments/20221219/c4ec338e/attachment.bin>