[Development] How to fix TableView's API break?
giuseppe.dangelo at kdab.com
Mon Dec 19 04:49:42 CET 2022
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
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* (!!!).
> 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?
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...
Size: 4244 bytes
Desc: Firma crittografica S/MIME
More information about the Development