>> 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?
The rationale behind it is that you normally would like to address a cell in a table using x, y coordinates. x maps horizontally and y maps vertically (to be consistent with e.g Item.x and Item.y). This means that x maps to columns and y maps to rows. itemAtCell(column, row) follows that thinking, since that is on the same format as writing itemAtCell(x, y). > > 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) > This is consistent with what I wrote above. > > Also the above functions are also inconsistently (and weirdly) overloaded > with overloads taking `point` (== QPointF). For instance: > > >> QModelIndex modelIndex(point cell) A point is specified using Qt.point(x, y), so again consistent with what I wrote above. I don’t find it weird that the API lets you also combine x and y coordinates into a point type. > >> 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* (!!!). Why do you find it “fun" that x maps to column and y maps to rows in this case? To me that is logical. Do you think x should map to rows instead? > 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? The API uses the term “position” whenever we talk about a pixel position, and “cell” whenever we talk about a table cell.This is consistent through out the API. The fact that we use point as type for them both should not be confusing when the function is called cellAtPosition. What else could _cell_ mean? Pixel position? > So, how to fix the above? One could easily fix the API break, but one is left > with broken APIs all over the place. You then assume that the API is semantically broken all over the place (not SIC), and it has been like for in the whole of Qt 6. I don’t think so. But if others agree, I would say that this is something to look at in an upcoming version of Qt. Not Qt 6.5? If TableView was written from the start, the API for itemAtCell would have been row, column and not column, row. Not because of the arguments above, but simply because it would be more consistent with the order you specify the coordinates to a QModelIndex. Whether you specify row first, or column first, in the API is not (in my eyes) wrong or right, but a matter of preference. But it should be consistent. > 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). That is a problem, yes. Good catch. Not sure how that sneaked in, but it needs to be fixed. But this doesn’t require an exception to the FF, we can surely fix up the API (added to Qt 6.5) after the FF? -Richard _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
