aboutsummaryrefslogtreecommitdiffstats
path: root/tests/auto/quick/qquicktableview/tst_qquicktableview.cpp
Commit message (Collapse)AuthorAgeFilesLines
* QQuickTableView: support unselecting cellsRichard Moe Gustavsen2024-04-171-15/+24
| | | | | | | | | | | | | | | | | | | | | | As it stood, SelectionRectangle and TableView didn't support unselecting cells by ctrl-dragging or ctrl-clicking a selected cell. This is considered a bug. This patch will therefore make sure that we support doing that. In order to implement this, we need to provide the held keyboard modifiers to startSelection(), so that TableView can choose if the selected cells should become selected or unselected in the selection model. By making this change, it also became clear that some of the auto tests didn't call startSelection() before setSelectionStartPos(). We therefore now also assert that we always do this, and fix up the failing auto tests that violated this rule. Fixes: QTBUG-121143 Pick-to: 6.7 6.6 6.5 Change-Id: Icd58b551234f3c6145165771de599e46b62014dc Reviewed-by: Santhosh Kumar <santhosh.kumar.selvaraj@qt.io>
* QQuickTableView: remove syncView from destructorRichard Moe Gustavsen2024-02-291-0/+16
| | | | | | | | | | | | If a TableView has a syncView, we need to ensure that it detaches itself from the syncView when it's destroyed. Otherwise the syncView will have a dangling pointer to the deleted TableView afterwards, which can cause a crash. Fixes: QTBUG-120760 Pick-to: 6.7 6.6 6.5 Change-Id: I4c6acfaa0c623ea43ba8b938585fcd9c9247f66c Reviewed-by: Santhosh Kumar <santhosh.kumar.selvaraj@qt.io>
* Correct license for test filesLucie Gérard2024-02-271-1/+1
| | | | | | | | | | | | | | According to QUIP-18 [1], all test files should be LicenseRef-Qt-Commercial OR GPL-3.0-only [1]: https://contribute.qt-project.org/quips/18 Pick-to: 6.7 Task-number: QTBUG-121787 Change-Id: I26d72e8de04d4c7c57b3b7838af5d033265de5ba Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io> Reviewed-by: Kai Köhne <kai.koehne@qt.io> Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* Fix crash issue in quick table view controlSanthosh Kumar2023-11-131-0/+27
| | | | | | | | | | | | | | | | | | | The quick table view can have both QAbstractItemModel and JS value as its model. The table view release and load the items (or rebuild) when its assigned with new model. The newmodel always be compared with existing model before rebuild via QQuickTableViewPrivate::syncModel. This comparison works with QAbstractItemModel but the same fails with JS model. This patch adds additional validation in QQuickTableViewPrivate::syncModel and QQuickTableViewPrivate::setModel for comparing JS model to avoid rebuild when existing model overwritten with same model again. Fixes: QTBUG-117917 Pick-to: 6.6 6.5 6.2 Change-Id: Ic15145c4b8998c68ae6471a2abf4aef727041eea Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* TableView: don't rebuild everything if row count changedRichard Moe Gustavsen2023-11-131-4/+9
| | | | | | | | | | | | | | | | | | | | | As it stood, TableView would rebuild the whole table if we got a call to forceLayout before a pending rowsInsertedCallback was delivered. This was far too harsh, as we a RebuildOption::All will throw away all existing delegates, and reset the contentItem back to zero. The correct thing to do, is to do the same that we already do in rowsInsertedCallback; just schedule RebuildOption::ViewportOnly. But since we don't know what else might have changed, we now also need to take the previous "else" case path in the function. Pick-to: 6.6 6.5 6.2 Task-number: QTBUG-118897 Change-Id: I23fe30c7d9e6abf32a6565c18bd9249de459636c Reviewed-by: Mitch Curtis <mitch.curtis@qt.io> Reviewed-by: Santhosh Kumar <santhosh.kumar.selvaraj@qt.io>
* TableView: don't emit rows and columns changed while rebuildingRichard Moe Gustavsen2023-11-091-0/+120
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We should be careful about emitting signals while we do a rebuild. The reason is that the application might listen to those signals and change Flickable properties (especially contentX/Y) behind TableView's back. A bug is seen from this if the application is setting a very large contentY upon receiving rowsChanged(). In that case TableView will not detect that it should do a "fast-flick" directly to the new contentY, but instead start to loadAndUnloadVisibleEdges() until it reaches the current viewport. And this can take a really long time, and therefore block the UI. This patch will wait to emit rows/columnsChanged until we're done rebuilding. At that point, it's safe to change properties such as contentX/Y from the application. The main usecase this patch is solving, is to be able to always position the viewport on the last row as new rows are added to the model. This can now be done by listening to onRowsChanged or onContentHeightChanged, and position the viewport at the end. The included auto test will therefore test this exact use case. Pick-to: 6.6 6.5 6.2 Fixes: QTBUG-118897 Change-Id: I6124fbd0e7097a2bbb89c887fe594c3028726aa7 Reviewed-by: Santhosh Kumar <santhosh.kumar.selvaraj@qt.io>
* QML TableView: resizable{Rows|Columns} scroll fixJonas Karlsson2023-09-211-0/+49
| | | | | | | | | | | The problem was that the table view resize handler accepted scroll events but did nothing with them. The fix is to simply not accept these events. Pick-to: 6.2 6.5 6.6 Fixes: QTBUG-116566 Change-Id: Ica4afc45908e1b4c0b8aac11a3798981b6250baf Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* QQuickTableView: let the subclass decide which model to use for selectionsRichard Moe Gustavsen2023-09-201-1/+1
| | | | | | | | | | | | | | | | | | | When a subclass that has a proxy model is in use, it's not given if the selection model should be using the application model or the proxy model to store selections. Rather, this is subclass specific. In case of TreeView, the application model should be used. In case of HeaderView, the proxy model should be used. Until now, we always used the application model, which would fail if trying to select cells in HeaderView. The reason for the latter is that the proxy model in HeaderView doesn't share any common model items with the application model, and therefore cannot use the application model for selections. Fixes: QTBUG-115227 Pick-to: 6.6 6.5 6.2 Change-Id: I39f0687e0396392039234787fda0df6d7d4d7da4 Reviewed-by: Santhosh Kumar <santhosh.kumar.selvaraj@qt.io> Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* Fix delegate loading issue when valid size is specifiedSanthosh Kumar2023-05-301-0/+12
| | | | | | | | | | | | | | The patchset ebefb583c886dba86aa51012fb377762235f2379 is made to avoid loading delegate when view port size is zero. But this affects the scenario when any of its size is valid in delegates. This patchset fixes delegate loading issue when valid size is specified in it. Fixes: QTBUG-113852 Pick-to: 6.5 Change-Id: Ib8b527175b91fefb8062f7ea5abc0c9b7860a0e7 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* TableInstanceModel: handle roleName invalidationRichard Moe Gustavsen2023-04-181-0/+15
| | | | | | | | | | | | | | | | | roleNames are generally guaranteed to be stable (given that QAIM has no change signal for them), except that resetting the model is allowed to invalidate them. TableInstanceModel did so far not take this into account. Handle this case correctly by snapshotting the current roleNames before the model is reset. Afterwards, if we detect that roleNames has changed, we throw the current model set up away and rebuild everything from scratch – it is unlikely that a more efficient implementation would be worth it. Fixes: QTBUG-111987 Pick-to: 6.5 6.2 Change-Id: Id1e3b8e4f983c0f00fc7b30bd4897f1f7fcc3792 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Quick item view tests: fix compile warningVolker Hilsheimer2023-04-181-1/+1
| | | | | | | | | | | Don't use QCOMPARE for a true/false test, use QVERIFY. This conveniently fixes the (bogus, perhaps) compiler warning with MSVC about comparing a quint32 (the underlying type of the polishScheduled bitfield) with a bool. Pick-to: 6.5 Change-Id: Ib273ee30906e09955e849e65af2b7ff8ce3e2512 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* Ignore tap events for table view when interactive is disabledSanthosh Kumar2023-04-111-0/+42
| | | | | | | | | | | | | | | | | | TableView uses QQuickTapHandler internally to handle tap events. This handler accepts tap events considering pointerNavigationEnabled property of table view. TableView accepts mouse events if either 'interactive' or 'pointerNavigationEnabled' property is set as true, otherwise, it has to pass mouse or touch events to the below item. This patch introduces QQuickTableViewTapHandler inherited from QQuickTapHandler that can explicitly check pointerNavigationEnabled property of QQuickTableView during wantsEventPoint to either accept or ignore tap events. Fixes: QTBUG-108596 Pick-to: 6.4 6.5 Change-Id: I330ae319706b6dbadc3a7319f62d636708aab995 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* QQuickTableView: only clear selections when selections are enabledRichard Moe Gustavsen2023-03-221-2/+17
| | | | | | | | | | | | | TableView should only modify a selection (which includes clearing it) when selections are enabled. Otherwise it should leave it to the application to modify the selection model explicitly. This can be used to set a selection that "sticks", regardless of what the user does. Pick-to: 6.5 Change-Id: I264946d1b3513846794e1fe12b7d94cfaef050ed Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* QQuickTableView: implement SelectedTapped correctlyRichard Moe Gustavsen2023-03-171-1/+6
| | | | | | | | | | | | | | | | The current implementation of SelectedTapped allowed the user to start editing when tapping on the _current_ cell. This is not correct, SelectedTapped is supposed to (like the name suggests) let the user start editing when tapping on a _selected_ cell. This patch will change the implementation so that the user can tap on a selected cell to edit it. Pick-to: 6.5 Change-Id: Ice5de9250c23f5f57e71077d4f46d1a3f31e9b80 Reviewed-by: Santhosh Kumar <santhosh.kumar.selvaraj@qt.io> Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* TableView: deprecate positionViewAtCell(column, row) in favor of ↵Richard Moe Gustavsen2023-02-131-9/+10
| | | | | | | | | | | | | | | | | | | | positionViewAtIndex(modelIndex) After deprecating modelIndex(column, row) in favor of index(row, column), we should now do the same to positionViewAtCell(column, row), to be consistent. This function will therefore deprecate positionViewAtCell(column, row) and instead offer a new function positionViewAtIndex(modelIndex). [ChangeLog][Quick][TableView] positionViewAtCell(column, row) has been deprecated in favor of positionViewAtIndex(modelIndex). Task-number: QTBUG-109542 Pick-to: 6.5 Change-Id: Id47f990a6148acdb7c1185c7f654d6f2b261b2ad Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* TableView: deprecate itemAtCell(column, row) in favor of itemAtIndex(modelIndex)Richard Moe Gustavsen2023-02-131-11/+11
| | | | | | | | | | | | | | | | | | After deprecating modelIndex(column, row) in favor of index(row, column), we should now do the same to itemAtCell(column, row), to be consistent. This function will therefore deprecate itemAtCell(column, row) and instead offer a new function itemAtIndex(modelIndex). [ChangeLog][Quick][TableView] itemAtCell(column, row) has been deprecated in favor of itemAtIndex(modelIndex). Task-number: QTBUG-109542 Pick-to: 6.5 Change-Id: Ibd009cb3b9d6ce7ba19da5e20df9e307a31f5090 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* TableView: deprecate modelIndex(row, column) in favor of index(row, column)Richard Moe Gustavsen2023-02-131-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Deprecate modelIndex(row, column) in favor of a new function index(row, column), starting from Qt 6.4.3. This has the advantage that we can print out a deprecation warning when modelIndex() is is used at run-time from QML. This will inform the developer early on that he should avoid using modelIndex(row, column), since the argument order differs between different versions of Qt. Relying on compile time deprecation macros alone will not work, since the API break is in a private class and only used publicly from QML (except for our own internal auto tests). Since the equivalent function in QAIM is also called index(row, column), this will additionally make the naming more consistent with the model classes. [ChangeLog][Quick][TableView] modelIndex(row, column) has been deprecated in favor of index(row, column). Task-number: QTBUG-109542 Pick-to: 6.5 6.4 Change-Id: Iec8f5f8fa2a0ca714153128717b546bbd62c7e2c Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* QQuickTableView: set active focus directly on the edit itemRichard Moe Gustavsen2023-01-201-0/+68
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When starting to edit a cell, the current implementation calls editItem->nextItemInFocusChain(true) to resolve the child to get active focus. But a better way is to instead rely on the edit item being a FocusScope. That way, we can simply set active focus on the edit item directly, and rely on the FocusScope forwarding active focus to the right child. After all, that is what FocusScopes are for. This patch will therefore change the implementation to set active focus directly on the edit item. But doing so turns out to cause tabbing from one cell to the next to stop working. The reason is that QQuickItem refuses to change setActiveFocusOnTab() on an item that has active focus. Instead, the focus item will eat the tab event, and use it to transfer focus to the next control in the chain. We therefore change the implementation to use an event filter on the focus object. That way, we're are guaranteed to always get a first shot at handling all critical key events that are needed for editing to work correctly. This includes tabbing, but even more imporantant, also Qt::Key_Enter, which is needed to allow the user to commit and close the editor. Pick-to: 6.5 Change-Id: I215b7efc52093eb0bd7f6a4fb60a57f83101e288 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* QQuickTableView: don't load any delegates if viewport has zero sizeRichard Moe Gustavsen2023-01-121-2/+40
| | | | | | | | | | | | | | | | When TableView has a zero size, the viewport will have zero size as well, and there is no reason to load any delegates. This patch will ensure that we return early from loadInitialTable() when we detect that this is the case. This will also stop a warning from being printed when the delegate has it's implicitWidth bound to tableView.width, and tableView.width == 0. Pick-to: 6.5 Change-Id: I659eb098f7c5c25c8359876f7664499381f94b98 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* QQuickTableView: never start to edit from a modifier key aloneRichard Moe Gustavsen2022-12-121-0/+10
| | | | | | | | | | | | | When TableView.editTriggers is set to AnyKeyPressed, the user can start to edit the current cell by pressing any key on the keyboard. But there are some exceptions, like the arrow keys. But it turns out that we also need to ignore the modifier keys, otherwise the user cannot e.g do a shift-drag to select cells without also starting to edit. Change-Id: I26ca954349823b50a605908633eb9c1d4996076a Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* QQuickTableView: let the edit delegate be a child of the cell delegateRichard Moe Gustavsen2022-12-071-0/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The first version parented the edit delegate to the content item of QQuickTableView. This approach, however, turned out make it really difficult to implement an edit delegate that relied on the geometry of items inside the tableview delegate. E.g for a TreeViewDelegate, we would like to show an editable TextField on top of the label while editing. But only on top of the label, not the whole delegate (including e.g the expanded/collapsed indicator). Moreover, we don't want to hide the whole delegate while editing, only the label that is underneatch (a possible semi-transparent) edit delegate. For this to be possible, we therefore need to parent the edit delegate to the TableView delegate instead, so that the edit delegate can e.g more easily query the geometry of the items inside the delegate (like the label) to position its own items (like a TextField). Since we also want the developer to then have more control over which items get hidden, we offer a property: "required property bool editing" to the tableview delegate. This can be used to e.g hide items inside the delegate while its being edited (or to implement other kinds of transitions). This new solution should also be easier to work with, and understand, for application developers, since the parent-child structure now mirrors the location where the edit delegate is written in QML. Change-Id: Ieeae28c8297f8bb1fb2d90d152fd575b4f41f36f Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* QQuickTableView: add layoutChanged() signalRichard Moe Gustavsen2022-12-051-0/+47
| | | | | | | | | | | | Add a new signal to TableView that tells when the layout has changed. This signal can be used to reposition any overlay on the content item, including e.g SelectionHandles. [ChangeLog][Quick][TableView] Added new signal 'layoutChanged()' Change-Id: I5b89a064521c2831279accbc889deb768d9b1a1b Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* QQuickTableView: implement TableView.editDelegateRichard Moe Gustavsen2022-12-011-0/+688
| | | | | | | | | | | | | | | | | | | This patch will implement support for editing cells in TableView. It enables you to attach an edit delegate to the tableview delegate, using the attached property TableView.editDelegate. The application can initiate editing by calling TableView.edit() (and TableView.closeEditor()) explicitly, or implicitly by using edit triggers. The EditTriggers enum in TableView mirrors the EditTriggers in QTableView (Widgets). [ChangeLog][Quick][TableView] Added support for editing cells Fixes: QTBUG-108838 Change-Id: I25df93a7eeabf9d8a4c4c6248e020d8eba6d5bd7 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* QQuickTableView: respect activeFocusOnTabRichard Moe Gustavsen2022-11-251-0/+46
| | | | | | | | | | | QQuickItem has a activeFocusOnTab property which should also be respected by TableView. When disabled, TableView should not transfer focus between the cells when the user hits the tab key. Change-Id: I234286926b58753fa50923321302d4fa108a4515 Reviewed-by: Oliver Eftevaag <oliver.eftevaag@qt.io>
* QQuickTableView: don't change index if tapping on the resize areaRichard Moe Gustavsen2022-11-161-12/+25
| | | | | | | | | | | | | | | | | | | | | The current implementation would change the current index when a single tap was done on the resize area between the cells. But doing that was not ideal if the tap turned out to be a double tap instead, since a double tap should only reset the column size. The current solution would solve this by using exclusive signals on the tap handler. But despite of that, it would still look wrong that a tap on the resize area, while the cursor has a resize appearance, changed the index. Using exclusive signals also comes with a small signal delay. So, all in all, it's simply better to change the logic so that the resize area is reserved for resizing only. And then, to change the current index, the tap needs to happen outside the resize area. Change-Id: I1e7cb8d1031d1b86c14d777c322f1717fa5eb171 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* QQuickTableView: add tab supportRichard Moe Gustavsen2022-11-161-0/+98
| | | | | | | | | | | Add support to TableView for navigating the current index using Tab and Backtab. [ChangeLog][Quick][TableView] Added support for navigating the current index using Tab and Backtab. Change-Id: I609ecce6e35a50ed436514ba38e0a0992807072f Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* QQuickTableView: detect if syncView topLeft has changedRichard Moe Gustavsen2022-11-111-0/+37
| | | | | | | | | | | | | | | | It can happen that the top left cell in syncView changes after a normal relayout. This is especially prone to happen if the cells used to be large, but are suddenly made much smaller, such that the top left cell ends up outside the viewport. This patch will detect this case, and ensure that the top left is being recalculated when they are no longer in sync. Pick-to: 6.4 6.2 Change-Id: I80cad2859a35e0f3bc58f101696112be7c084175 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* QQuickTableView: do a relayout whenever the view is resizedRichard Moe Gustavsen2022-11-111-1/+24
| | | | | | | | | | | | | | | | | | | | | | If you place a TableView in e.g a StackLayout, it will have a zero size until it becomes the active view the layout. If the delegate then has a binding that e.g looks like: implicitWidth: TableView.view.width it will fail, since the width of the view is zero at time of creation, but at the same time, never updated again once the view becomes visible (and resized). This patch will therefore ensure that we do a relayout each time the view is resized, since having such a dependency in the delegate (or in the columnWidthProvider) must be expected to be quite common. Pick-to: 6.4 6.2 Change-Id: I92f4f51f6b6c634c2627716c41ea4971fb8d1653 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* QQuickTableView: emit changes to leftColumn() _after_ it has been updatedRichard Moe Gustavsen2022-11-101-0/+28
| | | | | | | | | | | | An application might listen for e.g the leftColumnChanged signal and query the position to the delegate items in the new left column. But for this to work, be sure to layout the items (and basically finish loading the column) before emitting the signals, so that leftColumn(), rightColumn(), topRow() and bottomRow() return the correct values. Change-Id: I0e64bd2b240b0dac03120a944815ee2e5e43a6a0 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* QQuickTableView: implement support for letting the user resize rows and columnsRichard Moe Gustavsen2022-11-091-0/+338
| | | | | | | | | | | | | | | | | | | | | | | | | This patch will add support to TableView for resizing rows and columns by dragging between the cells. To achieve this, a custom pointer handler (QQuickTableViewResizeHandler) is implemented. This handler can detect if the pointer is hovering between the cells, and if the user starts a drag. This information is used to call out to the new setColumnWidth()/setRowHeight() API for adjusting the row and column sizes while the user is dragging. The pointer handler is careful to make sure that you can only start to resize by dragging _between_ the cells. If the drag starts elsewhere, the solution will fall back to normal contentItem dragging/flicking instead. Resizing is off by default. The user can enable it by setting the resizableRows/resizableColumns properties. In addition, an API that lets you query the state of the resizing has been added. [ChangeLog][Quick][TableView] Added resizableColumns and resizableRows properties to enable resizing by dragging between cells. Change-Id: I05d4170f30b8c6461a5877c2b831a1ab044d2b5b Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* QQuickTableView: ensure that column sizes are in sync when using a sync viewRichard Moe Gustavsen2022-10-241-0/+80
| | | | | | | | | | | | | | | | | | | | | | | | | | | | When a TableView has a sync child, it will decide the row and column sizes for it, so that the views are kept in sync. It can happen, though, that the geometry of the sync view is smaller than the geometry of the sync child. In that case, the sync child will show more rows and column than the sync view. This caused a bug when a TableView was placed inside a ScrollView with a HorizontalHeaderView on top (as a sibling of the ScrollView). In that case, the HorizontalHeaderView would actually be wider than the TableView, since the latter would be shrinked a bit to make room for a vertical scrollbar. The result would be that the HorizontalHeaderView would end up showing more columns than TableView. But Since TableView doesn't always know the width of a column that has not yet been loaded, the size of the header column would also end up wrong. This patch will make sure that the "virtual" viewport of the sync view is at least as large as the size of the sync children. This will ensure that we end up filling up a TableView with the same amount of rows and columns as any of the connected header views. Pick-to: 6.4 6.2 Fixes: QTBUG-107837 Change-Id: I32926738d48d6bd3b0892e6256a8f8d1ed5f1fa2 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* QQuickTableView: protect against delegate being deletedFabian Kosmale2022-10-191-0/+14
| | | | | | | | | | | | | | | While a delegate normally lives as long as the ItemView in which it is used, that can unfortunately not be guarantueed. As demonstrated in the test test case (and in a different way, in the bug report), it is possible to delete the backing Component, and end up with a dangling pointer in the table view. Avoid this by using a QQmlGuard to reset the pointer to null when the object gets deleted. Pick-to: 6.4 6.2 5.15 Fixes: QTEXT-7 Change-Id: I6407b19a35b9707a039c9b4b3b387f191589cda8 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* QQuickTableView: forward sync view calls to setColumnWidth/RowHeightRichard Moe Gustavsen2022-10-141-0/+58
| | | | | | | | | | | | | | | | | | | When a TableView has a sync view, the sync view will always decide the size of the rows and the columns. As such, also forward any calls to setColumnWidth/RowHeight to the sync view, otherwise it will have no effect. This is needed to e.g allow the application to resize the columns in a TableView by setting the size on the HeaderView instead. The opposite solution would be to just ignore any such assignments when having a sync view, but this would need to be documented as well, so then we might as well just forward the calls. Task-number: QTBUG-106792 Change-Id: Iadcd8c75677a69ab19fa2455274d340b5a4ad340 Reviewed-by: Paul Wicking <paul.wicking@qt.io> Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* Port from container::count() and length() to size() - V5Marc Mutz2022-10-131-8/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a semantic patch using ClangTidyTransformator as in qtbase/df9d882d41b741fef7c5beeddb0abe9d904443d8, but extended to handle typedefs and accesses through pointers, too: const std::string o = "object"; auto hasTypeIgnoringPointer = [](auto type) { return anyOf(hasType(type), hasType(pointsTo(type))); }; auto derivedFromAnyOfClasses = [&](ArrayRef<StringRef> classes) { auto exprOfDeclaredType = [&](auto decl) { return expr(hasTypeIgnoringPointer(hasUnqualifiedDesugaredType(recordType(hasDeclaration(decl))))).bind(o); }; return exprOfDeclaredType(cxxRecordDecl(isSameOrDerivedFrom(hasAnyName(classes)))); }; auto renameMethod = [&] (ArrayRef<StringRef> classes, StringRef from, StringRef to) { return makeRule(cxxMemberCallExpr(on(derivedFromAnyOfClasses(classes)), callee(cxxMethodDecl(hasName(from), parameterCountIs(0)))), changeTo(cat(access(o, cat(to)), "()")), cat("use '", to, "' instead of '", from, "'")); }; renameMethod(<classes>, "count", "size"); renameMethod(<classes>, "length", "size"); except that on() was replaced with a matcher that doesn't ignoreParens(). a.k.a qt-port-to-std-compatible-api V5 with config Scope: 'Container'. Change-Id: I58e1b41b91c34d2e860dbb5847b3752edbfc6fc9 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* Port from container::count() and length() to size()Marc Mutz2022-10-071-15/+15
| | | | | | | | | | | | | | | | | | | | This is a semantic patch using ClangTidyTransformator as in qtbase/df9d882d41b741fef7c5beeddb0abe9d904443d8: auto QtContainerClass = anyOf( expr(hasType(cxxRecordDecl(isSameOrDerivedFrom(hasAnyName(classes))))).bind(o), expr(hasType(namedDecl(hasAnyName(<classes>)))).bind(o)); makeRule(cxxMemberCallExpr(on(QtContainerClass), callee(cxxMethodDecl(hasAnyName({"count", "length"), parameterCountIs(0))))), changeTo(cat(access(o, cat("size"), "()"))), cat("use 'size()' instead of 'count()/length()'")) a.k.a qt-port-to-std-compatible-api with config Scope: 'Container', with the extended set of container classes recognized. Change-Id: Idb1f75dfe2323bd1d9e8b4d58d54f1b4b80c7ed7 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* QQuickTableView: add API to set section sizes explicitlyRichard Moe Gustavsen2022-10-071-0/+283
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add API in TableView for setting column and row sizes explicitly. Up till now, the recommended way to set column widths in TableView, was to use a columnWidthProvider (or simply rely on the implicit width of the delegates). The reason is that this scales much better, compared to imperatively setting all the column widths up-front, e.g at application start-up. But there are several cases where this API becomes a bit cumbersome to use, epecially for smaller data models, or when the rows and columns should be allowed to be resized at run-time. One such usecase is the ongoing work of supporting section resizing in HeaderView. This patch will therefore add an API that allows HeaderView, as well as the application, to set column and row sizes explicitly. More documentation on how this works is included in the patch. [ChangeLog][Quick][TableView] Additional API for setting explicit row-, and column sizes has been made available. Task-number: QTBUG-106792 Change-Id: I1cbcd36a57470580b2548442275a818a837ea2be Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* QQuickTableView: clear selection on tap directly in TableViewRichard Moe Gustavsen2022-08-111-0/+24
| | | | | | | | | | | | | Before 6.4, it was only possible to make a selection in TableView by using a SelectionRectangle. But in 6.4, you can also make a selection directly in TableView by using the shift+arrow keys. To make sure that a selection is cleared either way on tap, move the implementation that clears the selection from SelectionRectangle to TableView. Pick-to: 6.4 Change-Id: Ic718763bf9b643cb3e3c04cc3b90c6ffcf9ca4b2 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* QQuickLoader: Remove QQmlV4Function usageFabian Kosmale2022-08-031-1/+1
| | | | | | | | | | | | | Just add a normal overload set. Unfortunately, one overload would conflict with the plain setter of the source property; but we need a difference in behavior: The plain setter should not resolve the URL, whereas the invokable should. Solve this by renaming the setter (can be done, as the type is private). Task-number: QTBUG-105139 Change-Id: I27db968935f6eeddd415ccc6cb8c06ad6f0cf896 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* TableView: Add a test for TableView with bound delegate componentsUlf Hermann2022-07-211-0/+54
| | | | | | | | Pick-to: 6.4 Task-number: QTBUG-104884 Change-Id: I7736e14743912e44212d47cc55cd04aa36b7676d Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Use SPDX license identifiersLucie Gérard2022-06-111-27/+2
| | | | | | | | | | | | Replace the current license disclaimer in files by a SPDX-License-Identifier. Files that have to be modified by hand are modified. License files are organized under LICENSES directory. Pick-to: 6.4 Task-number: QTBUG-67283 Change-Id: I63563bbeb6f60f89d2c99660400dca7fab78a294 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* QQuickTableView: add new property 'selectionBehavior'Richard Moe Gustavsen2022-06-031-4/+140
| | | | | | | | | | | | | | | | This patch will add a 'selectionBehavior' property to TableView. It will let the developer specify if the user should be able to select individual cells, rows, columns, or if selections should be disabled. This is equal to the selectionBehavior enum in QAbstractItemView. [ChangeLog][Quick][TableView] A new property 'selectionBehavior' has been added that specifies if the user should be able to select rows, columns, or cells. Change-Id: Ia8855ae032bb02d278b284ed35049d9237523139 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* QtQuickTest: add API for checking for polish at window levelMitch Curtis2022-06-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds a qIsPolishScheduled(QQuickWindow *) overload of qIsPolishScheduled(QQuickItem *) (added in 40d6072bc8a4df0fe1a16025fe30fe653463a446) and deprecates qWaitForItemPolished() (added in 7a3cad0619662b992154e075ec6b840bfc8a46a7) in favor of qWaitForPolish(), which has QQuickItem* and QQuickWindow* overloads. The existing functions that take QQuickItem are useful, but testing Qt Quick applications can be made even easier by allowing users to check if a window has any items that need to be polished. This information is already present (in QQuickWindowPrivate::itemsToPolish), so it's very efficient to check for. This is especially useful now that Qt Quick Layouts using polishing for their layouting, for example, as it's no longer necessary to find individual polishable items in complex hierarchies before proceeding to interact with child items. [ChangeLog][QtQuickTest][QQuickTest] Added QQuickTest::qIsPolishScheduled(QQuickWindow *) and QQuickTest::qWaitForPolish(QQuickWindow *) functions for verifying that updatePolish() was called on one or more items managed by a window. [ChangeLog][QtQuickTest][QQuickTest] Deprecated QQuickTest::qWaitForItemPolished(QQuickItem *). Use the new QQuickTest::qWaitForPolish(QQuickItem *) function instead. Fixes: QTBUG-93757 Change-Id: I95b6e051b3c9fd2fa93604f4d9ccda486bb29f9d Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* QQuickTableView: ensure we use the correct margins during key navigationRichard Moe Gustavsen2022-05-311-0/+51
| | | | | | | | | | | | | Ensure we use the correct margins when navigating with the arrow keys at the beginning and end of the table. When e.g navigating to the first column in the model, we want to flick the view all the way to the start, margins included. It should already have worked like this, but must have broke after earlier copy/pase operations. Change-Id: I438b20518602e4cc5b49e137f633a7f550a9dec8 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* QQuickTableView: add a 'subRect' argument to the positionViewAtCell() functionsRichard Moe Gustavsen2022-05-311-105/+251
| | | | | | | | | | | | | | | By providing a sub rectangle, TableView will position the view on the rectangle instead of the bounding rectangle of the whole cell. This is useful for large cells, where you either want to make sure that a specific part of the cell is visible, or you want to avoid any unnecessary scrolling if that is already the case. [ChangeLog][Quick][TableView] A new argument 'subRect' has been added to positionViewAtCell(). Change-Id: I03dce1cae050700c6c6d2165c6e975e35cbc9927 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* QQuickTableView: add a new 'alternatingRows' propertyRichard Moe Gustavsen2022-05-271-0/+13
| | | | | | | | | | | | | | | | Add a new property 'alternatingRows' that informs the delegate that it should alternate between rows. This is merely a hint, the delegate is free to ignore it. But our own internal delegates, like TreeViewDelegate, should not. [ChangeLog][Quick][TableView] Added a new property 'alternatingRows', which is a hint to the delegate to alternate between rows. Change-Id: I3f10e7280332b652d393348ff0d71cd73ce6fa4d Reviewed-by: Mitch Curtis <mitch.curtis@qt.io> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* QQuickTableView: make top-left cell current on first key pressRichard Moe Gustavsen2022-05-251-0/+53
| | | | | | | | | | | | If TableView has focus, but currentIndex is not yet set, the first press on an arrow key should make the top left cell current. This will also make sure that if you e.g collapse a tree node that contains the current index, you can still continue to navigate using the arrow keys. This is equal to how it works with widgets. Change-Id: I1cd6266cd1a8269f7a4f2b1af989fddfc8ccd3c0 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* QQuickTableView: let sync views sync margins as wellRichard Moe Gustavsen2022-05-111-3/+36
| | | | | | | | | | | If a TableView has a sync view that has margins, it needs to have the same margins set as well. Otherwise they will not end up exactly in sync when you flick on either of them. Fixes: QTBUG-101218 Change-Id: I598bf6ebc6c2e7b9627ad18f254717296eca662b Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* QQuickTableView: add currentRow and currentColumnRichard Moe Gustavsen2022-04-211-0/+72
| | | | | | | | | | | | | | | | | | | Add two new properties that can be helpful when styling a delegate that should render differently depending on if it lies on the same row or column as the current item. "currentRow" will basically be the same as tableView.cellAtIndex(tableView.selectionModel.currentIndex).y. But that expression has the limitation that it will only update if currentIndex changes, and not as a result of layout changes inside the view (e.g when expanding or collapsing a node in TreeView). Using currentRow instead will not suffer from the same problem. [ChangeLog][QtQuick][TableView] Two new properties are added: currentRow and currentColumn. Change-Id: I1d4258196b299c4a3dfeb247dfc8f9b6a578b57e Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Fix tst_qquicktableview on AndroidAndreas Buhr2022-04-151-1/+1
| | | | | | | Pick-to: 6.2 6.3 Task-number: QTBUG-101865 Change-Id: Ieed455d57fad310b82a2b5d8f5dcf0a7f06301e4 Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
* QQuickTableView: for cells bigger than the view, prefer showing the top-left ↵Richard Moe Gustavsen2022-04-131-0/+47
| | | | | | | | | | | | | | | | | part When positioning on top a cell, PositionMode::Contain promises to make the entire cell visible. However, this is not possible for cells that are larger than the view. This patch will implement support for being able to specify that positionViewOnCell should prefer to align the cell bottom and/or right inside the view, but fall back to top and/or left if the cell cannot fit inside it. This is useful when navigating the current index around with the keyboard. Change-Id: I1d1f053dacee1ffd6c657254130066ab8fe9ecb6 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-21 18:49:17 +0000