[Development] Binding evaluation during ListView delegate remove animation

[Stephen Kelly]

On 20/01/16 01:23, Andrew den Exter wrote:
> On Wed, Jan 20, 2016 at 2:13 AM, Stephen Kelly 
> <stephen.kelly at ableton.com <mailto:stephen.kelly at ableton.com>> wrote:
>
>     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.
>

Indeed. What I have been considering is limiting the types which are 
cached to those which can directly be put into a user interface element 
- built in types like strings, numbers, colors etc. Maybe even any gadget.

It could be possible to special case model data which is-a OQbject 
pointer (QMetaType has API for that) and cache that too, but then we'd 
just be caching null pointers, so thinking this through leads me to 
think that's not useful.

That's the kind of design discussion that I would like to have in this 
thread though (as it is easier in email than in gerrit), so thanks for that.

> 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 implemented.
>

I think the cost would need to be measured before letting it influence 
design decisions. We are not talking about monstrous amounts of data.

> 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.

Indeed. That is an ad-hoc cache that a client can implement. It doesn't 
really scale well as a design, or as guidance for a team of developers.

>   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.
>

Yes, semantically this is quite similar to what I propose, but is not 
scalable.

> 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.

I don't think that solution is

* intuitive
* maintainable in a changing team
* easy to get right/hard to get wrong

so I don't really agree that it is 'simple'.

Thanks,

Steve.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160120/7d624d2b/attachment.html>