aboutsummaryrefslogtreecommitdiffstats
path: root/tests/auto/quick/qquicktableview
Commit message (Collapse)AuthorAgeFilesLines
* 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>
* QQuickTableView: check if the providers are undefined, not nullRichard Moe Gustavsen2018-08-211-2/+2
| | | | | | | | | | | | Checking if QJSValue isNull() will just check if it contains the js value "null". But we want to check if the application has assigned anything at all to the providers. Any value other than a function will not be accepted (which we check for at the time we try to call them (from resolveColumnWidth() and resolveColumnHeight()). Change-Id: I24717b67e99dd1ad6684a83125d2a4c7826dd501 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* QQuickTableView: set the stacking order of delegate items to 1Richard Moe Gustavsen2018-08-211-0/+1
| | | | | | | | | Let all delegate items have a stackin order (z) equal to 1. This is how ListView does it, so do the same in TableView to make them behave as similar as possible. Change-Id: I5d4629e8b116cd62c84e4fe9aefdb087e3c6e325 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* QQuickTableView: preload one extra row and column at start-upRichard Moe Gustavsen2018-08-141-9/+33
| | | | | | | | | | | | | | | | | | | | | | | When a TableView initially loads as many rows and columns it can fit inside the viewport, it will always be one less than the number it will show while flicking. The reason is that, as soon as you flick half a column out on the left, half a column will move in on the right. And this will increase the number of visible columns by 1 (but without reusing any items from the pool, since the first column is not out). Since this is always the case, it makes sense to preload one extra row and column at start-up, so that they're ready when the flicking starts. Note that this doesn't load more items in the background than what we need (like the cache buffer would). The viewport will fit _all_ the loaded items into the viewport once you start flicking. But the extra items loaded at start-up will instead be moved direcly to the pool for reuse, and the application will be informed about it (using the onPooled signal). Change-Id: Icea85c1d44f74ab54f1b96325489e8d6d1c0889e Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* QQuickTableView: be more precise about when to load and unload a columnRichard Moe Gustavsen2018-08-141-46/+35
| | | | | | | | | | | | | | | | The current implementation would unload a column/row if the right edge was greater than the right edge of the viewport. At the same time, it would load a column if the left edge was less than the right edge of the viewport. But we did nothing if the edge was exactly at the edge of the viewport. This patch will fix that, so that an edge is seen as either inside or ouside (and never on the edge). By handle this (corner) case, it will be easier to test the layout from the auto test, since a column will either be seen as inside or outside the viewport (and not exactly an the edge in addition). Change-Id: I95fccaa4a1bb583036027d2fc8c6eb4895eeefc8 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* QQuickTableView: rename attached prop tableView to viewRichard Moe Gustavsen2018-08-131-0/+1
| | | | | | | | ListView calls the same attached property for 'view'. So do the same for TableView. Change-Id: I99034869813750e2fab56fe6ffcc4b4a6a4d9c52 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* QQuickTableView: remove cacheBuffer from the public APIRichard Moe Gustavsen2018-08-1010-12/+0
| | | | | | | | | | | | | | | | | | As discussed during API review, remove cacheBuffer from the public API. The cache buffer was a feature inherited from ListView to avoid loading a lot of items (and affect performance) when the user started to flick. But now that TableView has support for reusing items, the point of the cache buffer is more or less gone. At least we choose to remove it from the public API until we have better understanding if this is really needed. Note that the cacheBuffer still plays a small role internally, so we don't remove it from the implementation. We want to preload an extra row and column for reuse at start-up, since you often cannot reuse the first row and column during the first flick (they will still be visible on the screen). Change-Id: Ie62835a04ac29a84c9a76151b73fe2f75d9ae844 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* QQuickTableView: add a 'forceLayout()' function to the public APIRichard Moe Gustavsen2018-08-102-0/+108
| | | | | | | | | | | | | | | | | This function needs to be called from the application whenever it needs to change column widths (or row heights) for the currently visible columns. Changing column widths is done by changing what values the columnWidthProvider returns. But TableView doesn't know that the assigned function has new values to return for the current columns. Calling 'forceLayout()' will inform about this, and trigger a re-layout. Change-Id: I3cf15bbfb522baf93c7e01a34841e54455a098b9 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io> Reviewed-by: J-P Nurmi <jpnurmi@gmail.com> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* QQuickTableView: override contentWidth/Height propertiesRichard Moe Gustavsen2018-08-091-0/+19
| | | | | | | | | | | | | | | | | TableView uses contentWidth/height to report the size of the table (this will e.g make scrollbars written for Flickable work out of the box). This value is continuously calculated, and will change/improve as more columns are loaded into view. At the same time, we want to open up for the possibility that the application can set the content width explicitly, in case it knows what the exact width should be from the start. We therefore override the contentWidth/height properties from QQuickFlickable, to be able to implement this combined behavior. This also lets us lazy build the table if the application needs to know the content size early on. The latter will also fix problems related to querying the content size from Component.onCompleted. Change-Id: Ife7ef551dc46cf15d6940e3c6dff78545a3e4330 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* QQuickTableView: change how we calculate content sizeRichard Moe Gustavsen2018-08-092-0/+163
| | | | | | | | | | The current calculations where a bit off. Change it to be precise, and add an auto test to verify the contentWidth/Height ends up correct as the flickable is flicked towards the end of the table. Change-Id: I784a1bba2ea8fddd09cee8ecda7e2089c8b5c74f Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* QQuickTableView: improve draining of reuse poolRichard Moe Gustavsen2018-08-072-2/+96
| | | | | | | | | | | | It turns out that using a maxTime of 2 when draining the pool was a bit naive. If e.g the width of the table is greater than the height, it starts releasing pooled items to quickly. So change the logic to be more dynamic, and to calculate what the maxTime should be based on the geometry of the table. Change-Id: Ifeed62789575f98cff063f550f45eb54ef312fdb Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* QQuickTableView, auto test: ensure we flick more than one pageRichard Moe Gustavsen2018-08-071-1/+1
| | | | | | | | | The included test only flicked one page while testing reusing of items. This must have been an oversight. It should flick several pages while running the test. Change-Id: I74899a540c9428c663bbf35b78e260c26ddaf700 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* QQmlTableInstanceModel: handle model data changes more gracefullyRichard Moe Gustavsen2018-08-023-10/+73
| | | | | | | | | | | | | Equal to QQmlDelegateModel, we need to listen for changes done to existing model items, and notify existing delegate items about it. Otherwise, they will not stay in sync with the model. By accident, this sort of worked in QQuickTableView already, since it would rebuild the whole table for every model update. This is really slow, and completely unnecessary. Change-Id: I10750ff387f8b455d0f27c50a17926d9beb6dd03 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* QQuickTableView: implement support for reusing delegate itemsRichard Moe Gustavsen2018-08-023-11/+306
| | | | | | | | | | | | | | | | | | | | | | | | This patch will make use of the recent changes in QQmlTableInstanceModel to support reusing delegate items. The API in TableView to enable this will mainly be a new property "reuseItems". This property is true by default. By setting it to false, reusing items will never happen. When an item is reused, the signal "TableView.reused" is emitted after the fact, in case the delegate item needs to execute some extra code during the process. Likewise, a signal "TableView.pooled" is emitted when the item is pooled. From an implementation point of view, TableView only need to do two things to enable reusing of items. First, whenever it releases items, it provides a second argument to release(), informing QQmlTableInstanceModel if the item can be reused. Second, it needs to call drainReusePool() at appropriate times to ensure that no item will be kept alive in the pool for too long. Change-Id: I830e2eace776302ac58946733566208aa8954159 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* tst_qquicktableview: check size hint for row/column, not implicit sizeRichard Moe Gustavsen2018-07-211-10/+16
| | | | | | | | | | The tests as it stood were wrong. We should not check that each item in a row/column has the size of the delegate, but instead check that each item has the same size as the sizeHint for the given row/column it's in. Change-Id: Iac01f8137b04ec701e575c5abafbbe30ebafabe6 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* tst_qquicktableview: don't set column count to 0Mitch Curtis2018-07-191-3/+1
| | | | | | | | It doesn't really make sense to do this, and it causes errors in delegates where "modelData" is undefined. Change-Id: Iddab63417d45f1b07cf8f66240f3aa0adcfeafdd Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* tst_qquicktableview: actually test that model is resetMitch Curtis2018-07-192-3/+25
| | | | | | | | I added the test but didn't call beginResetModel()/endResetModel()... whoops. Change-Id: Ia74a83562c2df689b4bbc00df1b7181b40e82d87 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* QQuickTableView: set delegate parent early-onRichard Moe Gustavsen2018-07-192-0/+20
| | | | | | | Set the parent before bindings are evaluated. Change-Id: I370524fe32c66699bd73aafeac55c58667b4dff1 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* QQuickTableView: remove TableView.cellWidth/HeightRichard Moe Gustavsen2018-07-183-5/+5
| | | | | | | | | | | | | The attached properties TableView.cellWidth/Height were added for corner cases where you couldn't set/override implicit size for a delegate item. But now that we have added rowHeightProvider and columnWidthProvider (and we know that we're going to offer a broader API to set row/column size from a HeaderView), you have a way out for those cases as well. So lets remove the attached properties until we know for sure if they will be needed. Change-Id: I7d20fb02c36aebd3f24964630ccb68d4c813e93e Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* Qt Quick Table View: set the default row and column spacing to 0Nicolas Ettlin2018-07-182-0/+107
| | | | | | | | | | | | | | | Currently, in the TableView QML component, the initial row and column spacing is set to (-1, -1), as in the default QSizeF constructor. As the negative spacing was ignored when positioning the items, but taken in account when computing the total content size, it caused an issue where the user wouldn’t be able to scroll to the bottom right corner of the TableView. This commit fixes this issue by setting a default spacing to (0, 0). It also prevents the developer from using invalid spacing values (such as negative numbers, NaN or Infinite). Task-number: QTBUG-69454 Change-Id: I343475790c384954372afad0a778f8da7dff0b0d Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* tst_qquicktableview: make checkRowColumnCount() more stableRichard Moe Gustavsen2018-07-181-4/+16
| | | | | | | | | | tst_QQuickTableView::checkRowColumnCount() was prone to fail, since it compared the maximum number of created delegate items to the initial count before flicking. But as we flick, TableView will normally need to load and show an extra column and/or row compared to the start. Change-Id: If39ae6eeff9a85acbc84cc61b8b94ee68565e347 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* QQuickTableView: change how tableview resolves column width and row heightRichard Moe Gustavsen2018-07-184-0/+405
| | | | | | | | | | | | | | | | | | | | | | The current solution of storing column widths as the user flicks around turns out to not scale so well for huge data models. We basically don't want to take on the responsibility of storing column widths and row heights for e.g 100 000 rows/columns. Instead, we now choose to ask the application for the sizes, whenever we need them. This way, the application developer can optimize how to store/calculate/determine/persist row and column sizes locally. To implement this functionality, we add two new properties: rowHeightProvider and columnWidthProvider. They both accept a javascript function that takes one argument (row or column), and returns the corresponing row height or column width. If no function is assigned to the properties, TableView will calculate the row height / column width based on the currently visible items, as before. Change-Id: I6e5552599f63c896531cf3963e8745658ba4d45a Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* TableView: invalidate table when model is resetMitch Curtis2018-07-172-0/+98
| | | | | | | | Signals like rowsInserted() were already accounted for in QQuickTableViewPrivate::connectToModel(), but modelReset() was not. Change-Id: I6b8248d745d507d4ea846e9bee717182915792b3 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* QQuikTableView: use TableViewModel instead of QQmlDelegateModelRichard Moe Gustavsen2018-07-171-6/+0
| | | | | | | | | | | | Swap out QQmlDelegateModel in favor of the new QQmlTableInstanceModel. QQmlTableInstanceModel skips using QQmlChangeSets all together, and lets us subscribe to model changes directly from the underlying QAIM instead. This will make it much easier to handle model changes more gracefully later. Change-Id: I0315e91f39671744fb48d1869e4b73b1becbb929 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* TableView: remove row and column from attached objectRichard Moe Gustavsen2018-07-101-15/+18
| | | | | | | | | | | | | | | | | | | TableView.row and TableView.column is no different from the row and column properties that are injected into the context from the model classes. So just remove them to not bloat the API. This attached properties where added at an early stage where we thought that it should be possible to set a different row and column count on the view than compared to the model (to e.g to "fake" a table layout when just assigning an integer as a model). Also, we consider supporting right-to-left etc, where we might end up with cells that have a different row/column in the view compared to where the cell is in the model. If we decide to do this later (not for the first release), we can consider adding the attached properties back again at that point. Change-Id: I588a45913b968db789978339bc9a63cd2ccfad49 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* QQuickTableView: use QHash instead of QList to store delegate itemsRichard Moe Gustavsen2018-06-261-40/+6
| | | | | | | | | | Using a QList to store all loaded delegate items was a legacy solution inherited from QQuickItemView. But we look-up items in the list based on index all the time, so switching to use QHash instead should be more optimal. Change-Id: I1aa8d23b3ac208a9424982491faaa5dd42775280 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* QQmlDelegateModelItem: move row and column up to the base classRichard Moe Gustavsen2018-06-092-1/+48
| | | | | | | | | | | | | | | | Change 8c33c70 injected row and column (alongside index) into the QML context of a delegate when the view had a QAbstractItemModel as model. Rather than only inject those properties when using QAIM, this patch will move the code to the base class. This way, if a view uses e.g a javascript list as model, row and column is still be available. This is useful, since then the delegate can bind to both row and column regardless of what kind of model the view uses. In the case of a list model, the column property will always be 0. Change-Id: I1d9f11c0b7d7a5beb83198184ba12cc1e48cd100 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* TableView: fix copy/paste failureRichard Moe Gustavsen2018-06-091-9/+13
| | | | | | | | | This patch fixes a small typo originated from an earlier copy/paste. QQuickTableViewPrivate::rowHeight() should use cellHeight, not cellWidth. Change-Id: I85cb3730dfd0daf0a9bb16dbb0771c31a453fa13 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* TableView: fall back to use implicit size for delegate itemsRichard Moe Gustavsen2018-06-042-0/+89
| | | | | | | | | | Rather than forcing users to set TableView.cellWidth/cellHeight (and therefore also force them to create an attached object for every cell), we now also accept setting implict size as a fall back. Change-Id: I4c4c4d23fe7fc193581728d3878cf2c7e40c0745 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* TableView: switch to use TableView.cellWidth/cellHeightRichard Moe Gustavsen2018-05-282-4/+4
| | | | | | | | | | | | | | This is logically more correct since TableView will override width / height anyway to make the delegates fit into the table if they are not as wide/tall as the widest column/row. And it gets even more problematic when we recycle delegates, since in that case we need to keep the original width binding of the delegate to calulate the size of new columns. And this all fits better by using attached properties instead. Change-Id: Ia5f2acd2bfc45f3fb160c3782191ad8da9f780e6 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io> Reviewed-by: J-P Nurmi <jpnurmi@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-19 10:16:34 +0000