| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We used to do "static_cast<QQuickItem *>(window->focusObject());". But
window->focusObject() returns a QObject, which doesn't have to be a
QQuickItem. And in fact, during start-up, focusObject() will point to
the window itself. The result is that we could sometimes get a crash
because of this.
This patch will change the implementation to use qobject_cast instead.
Change-Id: Id5335a8efb4b2d400e308bf6c27158a406fc781e
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>
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
| |
We need to clear the columnRowPositionsInvalid flag during
a rebuild, otherwise it will get processed later, resulting
in an unnecessary extra layout at startup.
Change-Id: I04d594c1b762e46b5b672113008b2bd67bf602d4
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 we don't set an implicit size on the fall back item, a
warning will be issued about it later in the process. This
is unnecessary, since we've already warned about not being
able to create the item from before.
Change-Id: I39dee52afe5d1918c9ee23204f2bed5315f7b113
Reviewed-by: Shawn Rutledge <shawn.rutledge@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>
|
|
|
|
|
|
|
| |
Change-Id: Ic6722a3cae6b3b6a3933206f14e0b6f6613609d8
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
Reviewed-by: Venugopal Shivashankar <Venugopal.Shivashankar@qt.io>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
| |
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 (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>
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
| |
Change-Id: Ib2a60bd8994bded2299ff96ac73137c9267398fa
Reviewed-by: Mitch Curtis <mitch.curtis@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>
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
| |
Task-number: QTBUG-69554
Change-Id: If094f213bf4daa383f8a5fd0ed22ad8100ab0675
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
| |
Like QQuickListView, QQuickTableView also calls updatePolish() directly
for a smoother drag/flick experience. But this can easily result
in recursive callbacks to viewportMoved() if the application, upon
receiving signals, changes contentX/Y. So add some extra code to
protect from this.
Change-Id: Ie4b29bdcf4dc650d89759f9a8a1e3378074ade6e
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
|
|
|
|
|
|
|
|
| |
Similar to e792c08ef2bb4d4676df2fe7cc4537ea993d07d2, except for rows
and columns being moved.
Change-Id: I2ffa18a7447730fdc32e298b2870cd3180c3bee8
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
|
|
|
|
|
|
|
| |
Set the parent before bindings are evaluated.
Change-Id: I370524fe32c66699bd73aafeac55c58667b4dff1
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.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>
|
|
|
|
|
|
|
|
| |
It's not useful to know the modelIndex without the count that it
exceeded. Also, print the names of the variables.
Change-Id: I97d83dad3980fa0fc3d85759a2adfb2b723a6ce1
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io>
|
|
|
|
|
|
|
|
| |
This way, you can just paste the path into e.g. Creator's locator
instead of having to find the application's build directory yourself.
Change-Id: If44d8fdf8c3c14c64a1f28432b13b8bdd9f80863
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io>
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
| |
Change-Id: Id2f4c9ad64fafbf7d65f4597250aef86871ff5b5
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In 2f9afadd5d9b4899397dca, we introduced a change in QQmlAdaptorModel
so that a QAIM model report that it contains "rows * cols" number of
model items, and not just "rows". This was needed, otherwise TableView
would only display the first column of such models.
It turns out, however, that also ListView will now detect that a
QAIM contain more items than just the items in the first column.
The result will be that it ends up adding all the other columns
underneath the first column in the view.
To avoid this unforseen change, this patch will revert this logic, and
instead add a private variable that can be set if the new behavior
is wanted (e.g by TableView).
Change-Id: I8c13da99f05e2f922362e498d1fa1779cdbd0d72
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
|
|
|
|
|
|
|
|
|
|
| |
Even if fine-grained support for model changes is not implemented
yet, there is no need to set/unset the model. An invalidate is
enough, which will silently trigger a rebuild of the table without
emitting signals etc.
Change-Id: Id1bed9e0707f8afc3fbc6b457c39686774ff7e82
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
| |
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>
|