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>
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>
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>
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>
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>
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>
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>
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>
- 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>
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>
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>
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>
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>
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>
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>
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>
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>
Ensure we rebuild the table when the model emits 'layoutChanged'.
Fixes: QTBUG-71140
Change-Id: I70dac897830bf5a12ae6987920e388743fd358a1
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
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>
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>
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>
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>
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>
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>
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>
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>
"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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
Richard Moe Gustavsen
Ulf Hermann
Kari Hormi
Liang Qi
Friedemann Kleint
Mitch Curtis