aboutsummaryrefslogtreecommitdiffstats
path: root/tests/auto/quick/qquicktableview
Commit message (Collapse)AuthorAgeFilesLines
* Merge remote-tracking branch 'origin/5.14' into 5.15Qt Forward Merge Bot2019-12-102-23/+24
|\ | | | | | | Change-Id: Iadbdd0fb63ca2a9e0b186343f8b730e4114cd71b
| * QQuickTableView: set empty content size when table is emptyRichard Moe Gustavsen2019-12-091-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | From before we would bail out early from the rebuild process if we detected an empty table. A result from this is that we left both contentWidth and contentHeight unchanged. This patch will set an empty content size when the table is empty. The effect will be that the user cannot flick the view around based on the old size. Fixes: QTBUG-80505 Change-Id: I3ac080476269fd5906ce79fa007eabb59b5ff4b1 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
| * QQuickTableView: ensure we release items in the old model and not the newRichard Moe Gustavsen2019-12-092-14/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As it stood, we would wait to release loaded items until we started the rebuild process, if the old model was a DelegateModel. But at that time, the model would alread have been changed, so we would release the items by calling out to the wrong model. This patch will ensure that we always release the items immediately when syncing the model, which will also cover the case when the model is a DelegateModel. Fixes: QTBUG-80570 Change-Id: I1b06011f4795727d04d9cd8c20381f65552b8fe8 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
| * QQuickTableView: support assigning a DelegateModelRichard Moe Gustavsen2019-12-092-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Normally you either assign a model to TableView that already has a delegate (or don't need one), like DelegateModel or ObjectModel. Or instead you assign a QAIM model and a delegate directly. But if you assign both a delegate and an ObjectModel, TableView would be confused, and ignore the assigned model and instead create an internal wrapper model that ends up empty. This patch will ensure that we don't create a wrapper model in such cases, but instead forward the delegate to whichever model is assigned, even if it ends up as a no-op for models that don't use one. Task-number: QTBUG-80534 Change-Id: Idd220df08617c379dc7808ee1f41c862b78cc201 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
| * tst_qquicktableview: ensure test checks for correct error messageRichard Moe Gustavsen2019-12-091-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | Change 631ef67458 fixed a bug that wrote a wrong error message to the console. But there is a test that checks for that message that was also wrong (but for some reason the test passed in the CI, but it has started to fail locally). This patch will ensure that the test don't fail because we check for a wrong error message. Change-Id: I27e16b0f4aa6a0ffeb8c42f846c344436a41ad3c Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* | Merge remote-tracking branch 'origin/5.14' into 5.15Qt Forward Merge Bot2019-12-054-2/+166
|\| | | | | | | | | | | | | | | Conflicts: tests/auto/quick/qquicklistview/tst_qquicklistview.cpp tests/auto/quick/qquicktableview/tst_qquicktableview.cpp Change-Id: Ib46bc1c717cf524eea2fb3d876810c8d55747c91
| * QQuickTableView: Clear items before deleting the modelUlf Hermann2019-12-042-0/+78
| | | | | | | | | | | | Fixes: QTBUG-71374 Change-Id: I534b7612268bb9407844961267865f490d7ff7b2 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
| * tst_qquicktableview: fix warning about missing JS functionRichard Moe Gustavsen2019-12-043-2/+88
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Change 35fdf3a7b7 added a binding to a function in one of the QML files used for testing (plaintableview.qml). The problem is that this file is also used from other places where we wrap a QSharedPointer that points to the model inside a QVariant. And when assigning that variant to a TableView, the QML binding will see the QSharedPointer, and not the model it points to. And hence complain that the model doesn't have the API that is exported from the model. The easy fix is to just create a new QML file for the new test added, that has the binding, but assigns a QVariant that wraps the model directly without usign a QSharedPointer. Change-Id: Ic2b77426c2d700479a9b5f4007384661e2ca0801 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* | Merge remote-tracking branch 'origin/5.14' into 5.15Liang Qi2019-11-224-3/+120
|\| | | | | | | | | | | | | | | Conflicts: src/qml/qml/qqmlextensionplugin.cpp tests/auto/quick/qquicktableview/tst_qquicktableview.cpp Change-Id: Ic58d36a8532015bae30f2690063db9829b3bf372
| * TableView: use fetchMore() when scrolling to the end of the tableKari Hormi2019-11-203-0/+43
| | | | | | | | | | | | | | | | | | | | | | QQmlTableInstanceModel implements canFetchMore and fetchMore functions, but these are not called at any point in QQuickTableView. This change checks if additional data can be fetched when atYEndChanged signal is emitted. Fixes: QTBUG-78273 Change-Id: I49b41b09d9a218826b34f32cd9fe4724a6097b52 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
| * QQmlTableInstanceModel: always emit index changed when an item is reusedRichard Moe Gustavsen2019-11-143-0/+50
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When reusing a delegate item, it can sometimes happen that the item ends up being reused at the same location in the table as it had before it was pooled. And in that case, we don't emit changes to index, row and column since they technically didn't change. The problem is that the model might have changed in-between, e.g if a row has been removed. And in that case, row and column will, even when unchanged, point to other parts of the model. So all bindings needs to be reevaluated to ensure that the values they use are refreshed. This patch will therefore ensure that we always emit changes to the mentioned properties when an item is reused, regardless if they change or not. Fixes: QTBUG-79209 Change-Id: Icec201a43a30b9f677303fbf652baf6487621deb Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
| * autotest, tableview: silence compiler warningRichard Moe Gustavsen2019-11-121-1/+1
| | | | | | | | | | Change-Id: I311f0c21baa73521717ad98b2398d5469b9ac208 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
| * QQuickTableView::forceLayout(): rebuild table if the size of the model has ↵Richard Moe Gustavsen2019-11-121-0/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | changed An assert will trigger if forceLayout() is called while the model is being reset. The reason is that the forceLayout() schedules a relayout which assumes that the size of the model hasn't changed. But while layouting, it will try to fetch data from the model according to the old size, which will trigger an assert. This patch will add an extra path to forceLayout() that checks if the size of the model has changed, and if so, schedule a complete rebuild instead of just a relayout. Fixes: QTBUG-79395 Change-Id: If61658912d9e90c1a5aef9bc28083da20fa6ec76 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* | Merge remote-tracking branch 'origin/5.14' into 5.15Qt Forward Merge Bot2019-10-042-0/+116
|\| | | | | | | | | | | | | | | Conflicts: src/imports/qtquick2/plugins.qmltypes src/quick/items/qquickitemsmodule.cpp Change-Id: I841c65c9c131354788b4f3fcfe3d7ed27be316d5
| * Merge remote-tracking branch 'origin/5.13' into 5.14Liang Qi2019-09-122-0/+116
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: src/qml/jsruntime/qv4engine.cpp src/quick/handlers/qquicktaphandler.cpp src/quick/items/qquicktableview.cpp Done-With: Richard Moe Gustavsen <richard.gustavsen@qt.io> Done-With: Ulf Hermann <ulf.hermann@qt.io> Done-With: Shawn Rutledge <shawn.rutledge@qt.io> Change-Id: If9558a33f01693ce96420c094e0b57dfff0626cd
| | * QQuickTableView: always relayout after a rebuildRichard Moe Gustavsen2019-08-282-0/+116
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The current logic was based on the idea that if both rowHeight-, and columnWidthProveders were set, we didn't have to relayout the items at the end of a rebuild. Because in that case, the row and column sizes would already be correct after the initial load. This assumption turns out to be false, because the providers are allowed to return -1 to signal that the size of a row or column should use default values (meaning, calculated by TableView). And for those cases, we need to do a relayout at the end of a rebuild. Fixes: QTBUG-77074 Change-Id: I0e0f2fdca1cfa9e98f2a0a2b227c3715c16a70f9 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* | | Support required properties in model delegatesFabian Kosmale2019-09-123-0/+186
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | If a delegates declares a required property of a given name, and that name exists as a role in the model, we set the property accordingly. The same holds true for the special properties that come from the QQmlDelegateModel like "index" and "model". All roles are still injected into scope and thus accessible; changing this in Qt5 would be tedious or even impossible while still maintaining backwardscompatibility with delegates that do not use required properties. Change-Id: I4f388ba549c42f1ff9822bdb3b8357c4d45e4b66 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* | Fix some compiler warnings in testsFriedemann Kleint2019-07-121-1/+0
| | | | | | | | | | | | | | | | | | | | - Signedness of integer comparison - Unused parameters and variables - Ignored return values of QTest::qWaitForWindowExposed() (nodiscard) - float to int conversions Change-Id: Ibece620d3c980a5af3b7717486c841d8072ed8af Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* | QQuickTableView: don't recalculate content width while flickingRichard Moe Gustavsen2019-05-151-72/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are now three mechanisms in TableView that works together to ensure that the table ends up edge-to-edge with the content view. They are applied in the following order: 1. Adjust the content size, based on the predicted size of the table. 2. Adjust the origin and endExtend on the fly, if the content size is wrong. 3. Move the table directly to where it should be, in case we don't have time to wait for the origin to change. We could have, strictly speaking, setteled with just one of them, but choose to use them all at the same time for best flicking experience. Still, 1. and 2. sometimes step on each others feet when they both detect that something is a bit off, and adjust. So rather than adjusting the size of the content view every time we load a new row or column, we just keep the first prediction. And then we leave all later ajustments to 2. and 3. This turns out to be a more stable, and will avoid some glitches that occur when flicking using a scrollbar, if several mechanisms kick in at the same time. Change-Id: Ib551a0bf8f6ee59ac9b3556b9462c91adb9cc80b Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* | QQuickTableView: change implementation of enforceTableAtOrigin()Richard Moe Gustavsen2019-05-111-0/+161
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We set the size of the content view to be the size of the complete table. The problem is that the exact size will always be just a prediction, since we would otherwise need to iterate over all rows and column up front, to be able calculate the exact size. This is not acceptable when using non-trival table models. A side effect of this, is that is will be possible to flick the viewport further out than the actual end of the table, if the content view turns out to be larger than the table itself. From before we used to just move the whole table back into the viewport when that happened, which could be seen as a sudden jump of the table to a new position. This change will improve this logic so that we can avoid most visual jumps. Instead of moving the table around, QQuickFlickable supports moving the origin instead. So when we see that the table is not in sync with the content view, we simple move the origin to the edge of the table. The effect is that any flicking or ongoing momentum animation in QQuickFlickable will continue as if nothing happened. This is also the same logic used by QQuickListView. Change-Id: I6060b7e84b9489c8fa569e6ff41b958e3871f8e7 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* | QQuickTableView: sync viewport rect with syncView when rebuildingRichard Moe Gustavsen2019-05-091-3/+99
| | | | | | | | | | | | | | | | | | When moving contentX/Y, we also need to ensure that the viewport rect reflects the change. Otherwise we'll end up loading rows and columns somewhere else then under the viewport. Change-Id: Ifbd3d66b9b3a822414aefde9b5bd088274dfa2ad Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* | Autotest: add syncView tests for QQuickTableViewRichard Moe Gustavsen2019-05-032-7/+372
| | | | | | | | | | Change-Id: I0c311a4cc7d0765e234739c005cb68a60cfee129 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* | Move model types into their own libraryUlf Hermann2019-05-022-3/+3
| | | | | | | | | | | | | | | | | | | | The model types are not part of the core QML runtime and should only be loaded if you explicitly import them. We cannot enforce that in Qt5 as some of them are available from the QtQml import, but we can change it in Qt6. Change-Id: I1e49e84d748e352537ec2d4af901c034c91d038f Reviewed-by: Erik Verbruggen <erik.verbruggen@me.com>
* | QQuickTableView: remove superfluous rebuildScheduled propertyRichard Moe Gustavsen2019-04-111-8/+4
|/ | | | | | | | | We already have the variable 'scheduledRebuildOptions'. When this is set to something else than RebuildOption::None, it means that a rebuild is scheduled. Change-Id: I85cde5c45eba15023cd389ebb0ba86f9d58835ae Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* Merge remote-tracking branch 'origin/5.12' into 5.13Liang Qi2019-02-222-0/+99
|\ | | | | | | | | | | | | Conflicts: tests/auto/quick/qquicktableview/tst_qquicktableview.cpp Change-Id: If3bf1abc23a59c458be0bb862d92f2edcb16b79f
| * QQmlDelegateModel: guard new row/column properties with revision 12Richard Moe Gustavsen2019-02-212-0/+99
| | | | | | | | | | | | | | | | | | | | Tag the new 'row' and 'column' properties with revision 12. This will make sure that they cannot be accessed by the delegate unless the QQmlAdaptorModel has the correct minorVersion set. Fixes: QTBUG-70031 Change-Id: I49e67c37ab5b7925c7bca313bbb99f04d1387cc4 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* | QQuickTableView: add support for hiding rows and columnsRichard Moe Gustavsen2019-02-084-31/+263
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch will add support for hiding rows and columns to TableView. You can now hide a column by returning 0 width for it from the columnWidthProvider. The same can be done to hide a row (by using the rowHeightProvider). If you return NaN or negative number, TableView will fall back to calculate the size of the column/row by looking at the delegate items, like before. This to make it possible to hide some rows/columns, without having to calculate and return the heights and widths of the other rows and columns. [ChangeLog][QtQuick][TableView] Added support for hiding rows and columns by setting their size to 0 from the columnsWidthProvider/rowHeightProvider. Change-Id: If9e1a8db91e257d36cb2787bab4856e6201456ac Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* | QQuickTableView: use QMap instead of a QRect to keep track of loaded columnsRichard Moe Gustavsen2019-01-301-79/+76
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | TableView keeps track of which rows and columns that are loaded at any point by using a QRect called "loadedTable". loadedTable basically describes the top-left and bottom-right corner of the table that has been loaded (which also is what ends up visible on screen). But now that we prepare for making it possible to hide rows and columns, using just a QRect becomes to simple. A rectangle will only tell what the edges of the table are, but not if any of the rows and columns in-between are hidden and therefore not loaded. So a QRect(0, 0, 10, 10) will give us the impression that we have 10 visible columns on screen, but in reality, we might have a lot less. This patch will change this to instead use two QMaps to record loaded rows and columns. This will make it much more easy to deal with hidden rows and columns in upcoming patches. We use a QMap instead of a QHash/QSet to keep the list of columns and rows sorted, since we frequently still need to know the edges of the table, like before. Change-Id: I45736485c67042403b095e73b5f2effa411281d0 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* | tst_qquicktableview: use QQuickTest::qWaitForItemPolished()Mitch Curtis2018-10-312-2/+4
|/ | | | | Change-Id: Iac53158bdd5138f41e5cc8d8fe1e1a5f7959be23 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* TableView: connect to 'layoutChanged' signal from the modelRichard Moe Gustavsen2018-10-172-2/+51
| | | | | | | | Ensure we rebuild the table when the model emits 'layoutChanged'. Fixes: QTBUG-71140 Change-Id: I70dac897830bf5a12ae6987920e388743fd358a1 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* QQmlAdaptorModel: return correct column count from the modelRichard Moe Gustavsen2018-10-172-0/+2
| | | | | | | | | | | There is no reason for QQmlAdaptorModel to return the wrong column count to the view. For models that are not QAIM, the accessor that wraps the model will report the column count to be 1 anyway. The same is also true for QAbstractListModel. Change-Id: Ia259b044201d76743e5f43d9f0999d3848912075 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* QQuickTableView: improve performance when scrolling with scrollbarsRichard Moe Gustavsen2018-09-291-2/+95
| | | | | | | | | | | | | | | | | | | | | When flicking, the current implementation would load and unload edges around the table until the new viewport was covered. The downside of that strategy is that you if you move the viewport a long distance in one go, you will need to load and unload edges hidden outside the viewport until it catches up with the new viewport. It gets even worse if you flick with a scrollbar, since then you can end up flicking thousands of rows in one go. And this will keep tableview busy loading and unloading edges for a "long" time. This patch will fix this issue by checking how much the viewport changes during a flick, and select a strategy based on that. So if the viewport moves more than a page (which is the size of the viewport), it will schedule a rebuild of the table from the viewports new location, rather than trying to load and unload edges until it catches up. Fixes: QTBUG-70704 Change-Id: I88909e118ec0759a7b7a305c19ccc6670af6263b Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* QQuickTableView: build the table when the component is finalizedRichard Moe Gustavsen2018-09-173-4/+211
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | componentComplete() is called on us after all static values have been assigned, but before bindings to any ancestors have been evaluated. Especially this means that if our size is bound to the parents size, it will not be ready at that point. Since we cannot build the table without knowing our own size, we waited for the updatePolish() call before we started to build the table. The problem with that strategy, is that any asynchronous loaders that TableView might be inside would already be finished by the time we received the updatePolish() call. The result would be that we ended up loading all the delegate items synchronously instead of asynchronously. (As soon as a loader has finished loading the initial item, async loading will no longer be used). This patch will therefore add a componentFinalized function that gets called after all bindings have been evaluated, but before the loader has finished. When receiving this call, we load the delegate items (and build the table). A nice side effect is that the table will also be ready by the time Component.onCompeted is emitted to the QML app. This means that e.g contentWidth/Height has valid values. Change-Id: Ief92d2fecfaea54f6191da116ed4ba79cc673b01 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* QQuickTableView: sync model and delegate when ready to do soRichard Moe Gustavsen2018-09-132-0/+128
| | | | | | | | | | | | | | | | | | Doing (silly) things in the delegate, like: Component.onCompleted: TableView.view.delegate = null will lead to a crash. The same if you change the model. The reason is that you end up changing the model while e.g a row is half-way loaded. Information needed for building the row, like model size, will then be invalid. To protect against this, we insert a "sync" phase to the code that takes any such changes into effect at a time when we know it's safe to do so. Change-Id: I85a992dfc0e04ec6635b10c9768a8ddc140e09da Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* QQuickTableView: override fixup() to preserve contentX/Y at start-upRichard Moe Gustavsen2018-09-112-13/+21
| | | | | | | | | | | | | | | | Flickable::fixup() will be called from Flickable::componentComplete(). fixup() is a virtual function that subclasses can override to e.g ensure that cells snap to grid etc (which is not yet supported by TableView). The default implementation will check if the assigned contentX/Y is within the current content item size, and adjust it back to 0,0 if not. The problem is that during componentComplete(), the table has not yet been built. And we don't want Flickable to reset any assignments to contentX/Y until that has happened. So override the function and block it from doing any adjustments before the table has been built. Change-Id: Id6c5a3b5f053f71bf1854573cd5b9dc3ecc9f246 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* QQuickTableView: don't rebuild table upon querying content sizeRichard Moe Gustavsen2018-09-111-3/+8
| | | | | | | | | | | | | | | | | | | | | | Overriding contentWidth/Height was done to be able to force build the table early if the app needed to know the size of the table already at Component.onCompleted (to e.g center the viewport on the center of the table). But now that we have a forceLayout() function, it's better to require that that function should be called before querying contentWidth/Height at this stage. By not building the table on the fly, we allow the application to bind expressions directly to contentWidth/Height, without being concerned about potential binding loops that can occur as a result of us rebuilding the whole table behind his back. The benefit of this overshadows the need to call forceLayout() explicit for some corner cases. Note that we still redefine the contentWidth/Height properties in TableView so that we can catch if the application sets an explicit contentWidth/Height (which is tested by checkExplicitContentWidthAndHeight()). Change-Id: Ic4499b3939af1cb3a543e4c006023d0d6f12fd3b Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* QQuickTableView: don't set contentX/Y to zero when building the tableRichard Moe Gustavsen2018-09-102-0/+91
| | | | | | | | | | | | Don't reset the content item to 0,0 when we do a rebuild of the table, since that will overwrite whatever the user has set to contentX/Y explicitly. Doing the latter can be handy if he needs to flick the table to a start position upon construction. If the user want's to move the content item back to origin when changing the model, he can instead do so manually. Change-Id: Ic7bc424312569e49115dea5037dd1109261a3aff Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* QQuickTableView: don't override margins API in TableViewRichard Moe Gustavsen2018-09-101-99/+19
| | | | | | | | | | | | | | | | | | | | | | Flickable has a margins API with the exact same naming as the margins API in TableView. This means that overriding those properties in TableView was an oversight, and a mistake. This patch will therefore remove the margins API from TableView. However, since the API already exists is in Flickable, the resulting API remains unchanged. But it will ease the TableView implementation a bit, since we can then remove code that takes margins into account (since Flickable does this automatically for us). The only real difference that will take effect from this change, is that any overlay or underlay items inside the flickable will need to have negative coordinates if you want to position them on top of the margins (e.g to create a header on top of the table). Change-Id: I43af66e49f5ddff90739a1c789aacb77ed18b4ce Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* QQuickTableView: remove focus for the delegate item itself, not only for the ↵Richard Moe Gustavsen2018-09-072-11/+25
| | | | | | | | | | | | child "isAncestorOf" will not include itself as an ancestor. So we need to check if the delegate item has focus as well, since we also want to remove focus for that case. This can e.g happen if the delegate is a TextInput directly. Change-Id: I5a5f5a7ec262eacdac64d72b0f41bca991dbab73 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* QQuickTableView: clear focus when delegate item with focus is flicked outRichard Moe Gustavsen2018-09-062-0/+108
| | | | | | | | | If we flick out a cell that has keyboard focus, we should clear that focus. Otherwise, the item will be focused also when it is later reused. Change-Id: I0fb79b6d906c1907a352de4ec52e3b488064b55a Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* QQmlTableInstanceModel: don't fall back to use DelegateChooser as delegateRichard Moe Gustavsen2018-09-062-0/+76
| | | | | | | | | | | If the application uses a DelegateChooser, but the chooser fails to resolve a delegate for a certain index, it should not use itself as the delegate instead. This will cause the application to crash. Instead, we just print a warning, and return nullptr, which will let TableView handle the situation gracefully. Change-Id: Ibaf9da09fd11149362f5b674fc61db47593de10c Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* QQuickTableView: add anchor check for delegateRichard Moe Gustavsen2018-09-062-0/+78
| | | | | | | | | If a delegate is using anchors, TableView will not be able to layout the item. So issue a warning if that is the case. Change-Id: I358d981067c23fdab2fc486003afc8bd685f940d Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* tst_qquicktableview: reuse the same QQuickView for all test casesRichard Moe Gustavsen2018-09-061-2/+11
| | | | | | | | | | | | Instead of creating a new view for every test (which will open a new window), it's better to reuse the same view. Especially since there is a bug in AppKit (which has been reported by Tor-Arne, but I could not find the rdar id) that can sometimes be hit when closing a window, causing it to crash. So creating and closing almost 100 windows in this test will sometimes trigger that bug. Change-Id: If4d962e4b9aeea154d4cd764a5bc414bcd2995b7 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* QQuickTableView: allow negative marginsRichard Moe Gustavsen2018-09-031-17/+31
| | | | | | | | | | | Currently TableView will hang when using negative margins. This patch will fix this so that negative margins will work as expected. An alternative implementations would be to only allow positive margins, but from an implementation point of view, there is really no reason to add such a restriction. Change-Id: Iea89212eb9d7f9d467955e27c70d9b7583a80d2e Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* QQuickTableView: handle RebuildOption::ViewportOnlyRichard Moe Gustavsen2018-08-271-0/+54
| | | | | | | | | | | When rebuildOptions have ViewportOnly set, we now let the top-left item be the same as before (and at the same position as before), and start rebuilding from there. This will greatly increase performance if e.g the table has been flicked far down to row 1000 when the rebuild needs to happen (e.g because the model got a new row). Change-Id: I30beb34a7beccedff8dc406f9a524119a2893eb3 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* QQuickTableView: only preload to pool if reuseItems is trueRichard Moe Gustavsen2018-08-271-4/+19
| | | | | | | | We move preloaded items into the pool. But this is pointless if we're not reusing items in the first place. Change-Id: I2274b0d29c98162da5fa4859c810c42093875836 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* QQuickTableView: don't overwrite rebuildStateRichard Moe Gustavsen2018-08-233-0/+131
| | | | | | | | | | Since it's fully possible to end up calling invalidateTable() while in the process of rebuilding the table, we need to ensure that we don't mess with the current rebuildState. Instead, just schedule that we need to rebuild once more later. Change-Id: If27bb14f0bc9f72c53eb47e6115d7ad580cdb516 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* QQmlDelegateModelItem: ensure that we emit changes to row and columnRichard Moe Gustavsen2018-08-222-0/+123
| | | | | | | | | | | | | As it stood, we would only emit changes to row and column if index changed as well. But when removing rows and columns from the model, it can happen that we reuse an item that by accident has the same index as the one we change it to, but belonging to a different row and column. So we need to check for changes to the index the same way we do for row and column. Change-Id: I9d507a74aa5dcb0fe7630e7af1e949bd2db7fb47 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* QQuickTableView: drain pool upon setting reuseItems to falseRichard Moe Gustavsen2018-08-221-0/+19
| | | | | | | | | | As (soon to be) documented, drain the pool immediately when setting reuseItems to false. This will give developers a way to clear the pool if e.g running low on memory. Besides, there is no reason to keep items in the pool if we're not reusing them. Change-Id: I49f0283721a63c6a6b92631f00c7ad711a262978 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* QQuickTableView: move TableView from Qt.labs to QtQuickRichard Moe Gustavsen2018-08-2210-10/+0
| | | | | | | | | | | TableView is now ready for Qt-5.12. The only thing missing is documentation, which is currently being written, and on the way. So remove the temporary labs plugin that used to register TableView, and register it together with the other QtQuick items. Change-Id: I7f360eac3934d228904a4133363e336afe0c451a Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>