On 20/01/16 01:23, Andrew den Exter wrote:
On Wed, Jan 20, 2016 at 2:13 AM, Stephen Kelly <stephen.ke...@ableton.com <mailto:stephen.ke...@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.
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
