aboutsummaryrefslogtreecommitdiffstats
path: root/src/quick/items/qquicktableview_p_p.h
Commit message (Collapse)AuthorAgeFilesLines
* TableView: ensure we rebuild the sync view, even when flicking on a sync ↵Richard Moe Gustavsen2020-10-231-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | view child When two table views are connect through the syncView property, both views will flick when you flick on either of them. This also means that if you fast-flick more than a page on the sync view child, the sync view needs to rebuild, like if you did the fast-flick directly on the sync view. Because we updated the sync view's viewportRect too soon while fast-flicking on the the sync child, we didn't detect that it was a fast-flick, and that a rebuild was needed. The result is that you could sometimes end up with the views getting out-of-sync. This patch will allow TableView to only move the viewport without updating the internal viewportRect while flicking. The viewportRect will instead be sync-ed at a later point, like we do when you flick on the sync view directly. This will ensure that we rebuild if needed, also while fast-flicking on the child view. Task-number: QTBUG-87821 Pick-to: 5.15 Change-Id: Ifc74473eb43406acaa8e24880066fb4ca89d3a4e Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* TableView: ensure we update content size upon model changesRichard Moe Gustavsen2020-10-211-3/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For tables of non-trivial sizes, we usually don't know what the content size will be unless we load all rows and columns, which we simply cannot do. Because of this, we have up till now chosen a strategy where we normally just calculate a predicted content size up-front, when we table is built, and afterwards just stick to that prediction. This strategy works for big tables that fills more than one size of the viewport, and if the number of rows and column in the model stays around the same. But for tables that start off smaller than the viewport, and later expands to grow out of it, it simply fails. And the failure is such that the tableview can get stuck, with no way way for the user to flick around to see the rest of the contents. An example is TreeView that might only show the root node at start-up, but as you start to expand the tree, it will quickly add more rows than what fits inside the viewport. And in that case, the contentHeight will be totally off, and in turn, make the scrollbar be based on wrong values, and sometimes not work at all (e.g if it has the flag Flickable::StopAtBounds). This patch will change the implementation so that we recalculate the content size whenever it should logially change. That is, if e.g the model add or remove rows and columns, or if you change spacing. This still doesn't mean that contentWidth/Height reports the correct size of the table, but at least it will be a better guestimate for smaller tables, and at the same time, work together with Flickable and ScrollBars. Pick-to: 5.15 Fixes: QTBUG-87680 Change-Id: Ie2d2e7c1f1519dc7a5d5269a6d25e34cf441b3fe Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* QQuickTableView: add functions to get current rows and columnsRichard Moe Gustavsen2020-04-091-0/+2
| | | | | | | | | | | | This API can be used to query and iterate the currently loaded rows and columns inside the view. [ChangeLog][QtQuick][TableView] Added the properties leftColumn, rightColumn, topRow, and bottomRow, which can be used to query which part of the model is currently visible inside the view. Change-Id: I06f99cc1e8da1004dc8614977f149192e1880ba4 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* QQuickTableView: add positionViewAtRow()/Column()Richard Moe Gustavsen2020-04-081-7/+27
| | | | | | | | | | | | | | Add functions to let the application scroll the table to a specific row or column using a specific mode. This API partially mirrors the API found in ListView. [ChangeLog][QtQuick][TableView] positionViewAtCell(), positionViewAtRow(), and positionViewAtColumn() have been added to enable the application to position the contents to show a specific cell. Fixes: QTBUG-83215 Change-Id: I321588041977f9ded40f84fc0499ea1c5f6ac801 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Merge remote-tracking branch 'origin/5.15' into devQt Forward Merge Bot2020-03-241-0/+4
|\ | | | | | | Change-Id: I9f0d5adf1ba7d3246b1107a20d145e7aac2c7a77
| * QQuickTableView: add private support for transposing the viewRichard Moe Gustavsen2020-03-231-0/+4
| | | | | | | | | | | | | | | | This is needed by HorizontalHeaderView when assigning it one dimensional models. Change-Id: I183f0d35b8f3a97853fc7496dc68b0e13e9be990 Reviewed-by: Andy Shaw <andy.shaw@qt.io>
* | Merge remote-tracking branch 'origin/5.15' into devQt Forward Merge Bot2020-02-171-1/+1
|\| | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: src/imports/qtqml/plugin.cpp src/qml/qml/qqml.h src/qml/qml/qqmlmetatype.cpp src/qml/qml/qqmlmetatype_p.h src/qml/qml/qqmltypeloader.cpp src/qml/types/qqmlbind.cpp src/quick/items/qquickitemsmodule.cpp tests/auto/qml/qqmlecmascript/tst_qqmlecmascript.cpp Change-Id: I52548938a582cb6510271ed4bc3a9aa0c3c11df6
| * Privately export QQuickFlickablePrivate and QQuickTableViewPrivateMitch Curtis2020-02-061-1/+1
| | | | | | | | | | | | | | | | | | We need this to implement header views (for TableView) in qtquickcontrols2. Task-number: QTPM-1300 Change-Id: I03068828cdf6dd79ec6a91c75f68eaf7c224d4a2 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* | Use QTypeRevision for all versions and revisionsUlf Hermann2020-02-031-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | In many places we carry major and minor versions or revisions that are loosely coupled to minor versions. As the Qt minor version resets now, we need to handle these things more systematically. In particular, we need to add a "major" part to revisions. QTypeRevision can express the current major/minor pairs more efficiently and can also be used to add a major version to revisions. This change does not change the semantics, yet, but only replaces the types. Change-Id: Ie58ba8114d7e4c6427f0f28716deee71995c0d24 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* | Merge remote-tracking branch 'origin/5.15' into devQt Forward Merge Bot2020-01-211-4/+6
|\| | | | | | | Change-Id: Ic2cea85917751b89c34768fd80d8b11f5706dd62
| * QQuickTableView: make syncView/syncDirection/model private implementation ↵Yulong Bai2020-01-201-4/+6
| | | | | | | | | | | | | | | | | | | | virtual For usage in HeaderView, moving getters/setters/sych-ers in private implementation virtual, keep public APIs clean and also make private implementations overridable. Change-Id: I4ad04665b7268354a49dc9711944ee0c6fd2738f Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* | Use QFlatMap in QQuickTableViewShawn Rutledge2020-01-151-8/+9
|/ | | | | | | | | | QFlatMap is implemented to use two containers internally, one for keys and one for values. This improves locality of reference for the purpose of doing binary search to find a key quickly, and also makes the keys() (and values()) accessor really fast. Change-Id: I87bbb06371aeb44c5bcf971d72ae9cd59920f800 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* TableView: use fetchMore() when scrolling to the end of the tableKari Hormi2019-11-201-0/+2
| | | | | | | | | | | 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>
* QQuickTableView::forceLayout(): rebuild table if the size of the model has ↵Richard Moe Gustavsen2019-11-121-1/+3
| | | | | | | | | | | | | | | | | | 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>
* QQuickTableView: change implementation of enforceTableAtOrigin()Richard Moe Gustavsen2019-05-111-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | 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: remove relayoutTable()Richard Moe Gustavsen2019-05-081-1/+0
| | | | | | | | | | It was only called from one place. And we can optimize it a bit by moving the contents to the caller. Besides, stray relayouts without rebuilding (RebuildOption::LayoutOnly) is no longer allowed. Change-Id: Id63bd2d71969b81ea999caa9d4d331abf8999704 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* QQuickTableView: protect fixup() from being called while resizing the ↵Richard Moe Gustavsen2019-05-021-0/+1
| | | | | | | | | | | content view Calling the base class implementation of fixup might move the content view and start animations etc, which will cause glitches. So ensure we don't do this when we adjust the content size internally. Change-Id: I214a6ae2da0c21fd733ea884bccb5e77fc554615 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* Move model types into their own libraryUlf Hermann2019-05-021-2/+2
| | | | | | | | | | 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>
* Add QQuickTableSectionSizeProvider for QQuickTableViewYulong Bai2019-04-301-0/+21
| | | | | | | Used to store columnWidths and rowHeights. Change-Id: Id66fba9de05afa2c4df15761fb004b4f046fe103 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* QQuickTableView: avoid building syncView children before syncView has finishedRichard Moe Gustavsen2019-04-291-1/+1
| | | | | | | | | | | | | | If you put two tables inside an async loader, with one being the syncView for the other, the syncView child will start loading items async simultaneously with the syncView. This is unnecessary, and steals loading resources, since the child will have to rebuild anyway once the syncView has completed loading. So return early from the recursiveUpdateTable call before handling the children if we detect that the parent is not done. Change-Id: I8c0badaf3cfa3a353a650e5f38f381bf9a7b98f9 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* QQuickTableView: update calculateTopLeft() to take syncView into accountRichard Moe Gustavsen2019-04-261-1/+0
| | | | | | | | | | | calculateTopLeft() takes care of finding which cell should be the 'corner stone' that needs to be loaded first when doing a rebuild. When we have a syncView, the top left cell should match the top left cell of the syncView, so the logic needs to change quite a bit to take this into account. Change-Id: Ia0b621a3155bbd113fa37c2ed585f16627d46443 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* QQuickTableView: update viewportMoved() to take syncView into accountRichard Moe Gustavsen2019-04-251-0/+7
| | | | | | | | | | | | Now that several table views can stay in sync through the syncView parent-child chain, we also need to ensure that the position of the content views stays in sync. This patch will recursively go through all connected views when one of the views are moved and set the same position on them all according to the syncDirection flag. Change-Id: I5a5b8e795426484eeab3771f6c8d4c9b7da046eb Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* QQuickTableView: implement recursive updateTable()Richard Moe Gustavsen2019-04-241-0/+4
| | | | | | | | | | | | | Now that a TableView can be inside a syncView hierarchy, we cannot update a table in isolation, but need to coordinate this with the other views. It's especially important that we update a parent syncView before a child syncView, to ensure that the parent has calculated all the necessary columns width and row heights. For that reason, we always update the table views starting from the top. Change-Id: Iba8ae7d28fa0bb2fbbad9f8fc7aa198e15b91872 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* QQuickTableView: add new 'syncView' propertyRichard Moe Gustavsen2019-04-231-0/+8
| | | | | | | | | | | | | | This property can be set to point to another TableView. If set, this TableView will be synchronized to the other table with respect to flicking, column width, row heights, spacing, etc. This logic is needed as a foundation for the upcoming HeaderView. Upcoming patches will implement this logic (together with autotests) gradually. Change-Id: Ic7dea8e1d1aa46bbb3ea6e795953a65c96c25cc6 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* QQuickTableView: improve checking rebuild status while rebuildingRichard Moe Gustavsen2019-04-211-1/+0
| | | | | Change-Id: I5e7b5b261d3ba28fbbf345f2fc3f086d87112a2d Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* QQuickTableView: combine layouts and rebuilds into the same code pathRichard Moe Gustavsen2019-04-211-6/+5
| | | | | | | | | | | Rather than handle relayouts differenty than rebuilds, we can make it a part of the rebuild structure instead, since they overlap a lot. That way we can collect everything that needs to be updated into a single variable (rebuildOptions). This will simplify the upcoming work for synchronizing tableviews. Change-Id: I8bb2638612c86194a854e6fefc998eae22357a7a Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* QQuickTableView: remove superfluous rebuildScheduled propertyRichard Moe Gustavsen2019-04-111-1/+0
| | | | | | | | | 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-221-0/+1
|\ | | | | | | | | | | | | Conflicts: tests/auto/quick/qquicktableview/tst_qquicktableview.cpp Change-Id: If3bf1abc23a59c458be0bb862d92f2edcb16b79f
| * QQmlDelegateModel: guard new row/column properties with revision 12Richard Moe Gustavsen2019-02-211-0/+1
| | | | | | | | | | | | | | | | | | | | 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-081-51/+68
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-3/+11
|/ | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* TableView: connect to 'layoutChanged' signal from the modelRichard Moe Gustavsen2018-10-171-0/+1
| | | | | | | | Ensure we rebuild the table when the model emits 'layoutChanged'. Fixes: QTBUG-71140 Change-Id: I70dac897830bf5a12ae6987920e388743fd358a1 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* QQuickTableView: improve performance when scrolling with scrollbarsRichard Moe Gustavsen2018-09-291-1/+6
| | | | | | | | | | | | | | | | | | | | | 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-171-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-131-0/+10
| | | | | | | | | | | | | | | | | | 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-111-0/+1
| | | | | | | | | | | | | | | | 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: be more precise about when to call updatePolish()Richard Moe Gustavsen2018-09-111-2/+0
| | | | | | | | | | | | | | | | | | | | | If a rebuild is scheduled, calling updatePolish() directly (which is just an optimization) will rebuild the table there and then. But we don't want this to happen upon a callback from viewportMoved(), since rebuilding the table will usually also change the geometry of the viewport/contentItem, which can easily trigger binding loops back to the place that made the viewport move in the first place. At the same time, we don't want to impose the same limitation when calling updatePolish() from forceLayout(), since that function is always called explicit from the application. And any binding loops caused by it can as such be avoided by the developer. This patch will therefore remove the common updatePolishIfPossible() function, and move the logic for when to call updatePolish back to the calling locations. Change-Id: I845b9469c61735d27fc28ebe9f7b254d5a9b2efd Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* QQuickTableView: don't override margins API in TableViewRichard Moe Gustavsen2018-09-101-1/+0
| | | | | | | | | | | | | | | | | | | | | | 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: handle RebuildOption::ViewportOnlyRichard Moe Gustavsen2018-08-271-2/+6
| | | | | | | | | | | 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: rename to scheduleRebuildTable, and add rebuild optionsRichard Moe Gustavsen2018-08-271-1/+11
| | | | | | | | | | | | | | | | | Rebuilding the table from scratch whenever e.g the model adds a new row or column is slow and unnecessary. What happens is that we always rebuild the table from the origin, and continue load and unload edges until the loaded rows and columns overlaps with the viewport. This can be slow if you are e.g at row 1000 when you start to rebuild. Instead we can just start from current position in the viewport. So add some options to control what needs to be done. Note: This patch doesn't change any logic as it stands. But the options will be used in a subsequent patch. Change-Id: I9705dbae3a2c04e7e7189ec453756358a1b9fc14 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* QQuickTableView: decide whether to reuse items from calling locationRichard Moe Gustavsen2018-08-241-1/+1
| | | | | | | | | This patch opens up the possibility to specify the reuse flag from the calling location. It doesn't change the current logic, it's just a preparation to simplify subsequent patches Change-Id: Id00dc8a354140b0e511564c40066d3a97a773c5c Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* QQuickTableView: don't overwrite rebuildStateRichard Moe Gustavsen2018-08-231-2/+3
| | | | | | | | | | 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>
* QQuickTableView: preload one extra row and column at start-upRichard Moe Gustavsen2018-08-141-3/+17
| | | | | | | | | | | | | | | | | | | | | | | 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: remove cacheBuffer from the implementationRichard Moe Gustavsen2018-08-141-9/+0
| | | | | | | | | | | | | | | | | | | | | | After we removed cacheBuffer from the public API, giving the users no way to switch if off, the safest thing is to also remove it from the implementation. The cache buffer can easily load add a lot of hidden items to the view, and the user now has no way to tweak or hinder it. As an example, lets say that you in a ListView can fit 10 items on screen. And then you have a cache buffer set that loads two more items, both on top and below. You then end up with 14 items added to the view. Now, lets consider the same case for TableView, where you show 10x10 items on screen. With the same cache buffer, you end up loading 2x10 items in the background on all sides of the table (pluss 4 items in each corners). This sums up to 96 extra items. This is really bad and unacceptable. It's more performant to just switch the caching off completely. Change-Id: Iddbd78ef1d7c7197eb4a847ec5067184149fe9a0 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* QQuickTableView: rename enforceFirstRowColumnAtOrigo to enforceTableAtOriginRichard Moe Gustavsen2018-08-101-1/+1
| | | | | Change-Id: Ib2a60bd8994bded2299ff96ac73137c9267398fa Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* QQuickTableView: override contentWidth/Height propertiesRichard Moe Gustavsen2018-08-091-0/+14
| | | | | | | | | | | | | | | | | 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>
* Add missing header guardJędrzej Nowacki2018-08-081-0/+5
| | | | | Change-Id: I58aaa65047c3b7244cb69a84117b41453ff9ee0a Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* QQuickTableView: don't access the model from the destructorRichard Moe Gustavsen2018-08-071-1/+0
| | | | | | | | | | | | | | Calling clear() from the destructor is problematic, since clear() will try to access the application model, which has typically already been destructed at that point. Instead we should just clean-up any local resources. Since we don't really have a need for the clear() function anymore, we move the code where it belongs: into the beginRebuildTable() function. Task-number: QTBUG-69554 Change-Id: Ic43704c71407e805427de27cf10dbdeeae475ba8 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* QQuickTableView: improve draining of reuse poolRichard Moe Gustavsen2018-08-071-0/+1
| | | | | | | | | | | | 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>
* QQmlTableInstanceModel: handle model data changes more gracefullyRichard Moe Gustavsen2018-08-021-1/+0
| | | | | | | | | | | | | 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>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-10 08:17:20 +0000