[Development] Binding evaluation during ListView delegate remove animation
Andrew den Exter
andrew.den.exter at qinetic.com.au
Wed Jan 20 01:23:10 CET 2016
On Wed, Jan 20, 2016 at 2:13 AM, Stephen Kelly <stephen.kelly at ableton.com>
> The remove animation happens as a result of the
> QAbstractItemModel::rowsRemoved signal, so there is a 'tension' between the
> 1. An attempt in the delegate to access the data while it fades out.
> 2. The row in the model providing access to that data has just been
> The solution could be to cache data retrieved from the model.
That's a more complex solution than you might think. It's a pretty popular
pattern to populate a model with QObjects for example and with a naive
cache of QVariants what was an admittedly annoying binding evaluation error
becomes a much more severe dereference of a dangling pointer.
And there are the obvious runtime costs to building and maintaining a cache
that is of little or no use to most people most of the time, which is I
think a strong argument for it being an off by default feature if
If you do have this problem, right now the solution is to bind the model
value to a property in your delegate and use the property in your binding.
The property binding will only be re-evaluated when the model data changes
so it won't ever try and access the model after the row has been removed.
It is an issue and by all means investigate a solution, but there is a
simple means to deal with it at a user level and I'm personally wary of the
complexity and repercussions of fixing it in the views.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Development