[Development] Binding evaluation during ListView delegate remove animation

[Stephen Kelly]

On 21/01/16 08:12, André Somers wrote:
>
> Actually, I think it would not need to be quite as bad.
> For starters, you really only need to cache the actual items being 
> removed. At the moment the model emits the AboutToBeRemoved signal, 
> the data should still be there in any well-behaved model, right? 
> _That_ is the moment you do your caching.
>

Even 'reasonable' qaim implementations might not still be able to give 
you data in a handler of rowsAboutToBeRemoved. Consider for example a 
qaim which models a filesystem. If the data() method is written to look 
at the filesystem, and QFSWatcher is used as a trigger to signal removal 
of rows, then by the time the rowsAboutToBeRemoved signal is emitted, 
the file is already gone from the filesystem.

QFileSystemModel solves that with an internal cache of QFileInfo 
instances, but you can imagine reasonable models which don't have an 
internal cache like that.

However, requiring models to have such a cache for exactly that reason 
could be reasonable. It is already kind of an implicit requirement of 
the use case you mention. It would become a more-explicit requirement if 
QML relied on it like that.

> While it is possible that because of conditionals in the binding roles 
> are accessed only during the removing, it does not sound very likely. 
> One could provide an API to specifically add roles to the caching 
> manually, but otherwise only cache roles that have been accessed 
> already. Or just only set the roles manually and use that as the 
> on/off switch for the whole feature that Andrew requested. 
> Realistically, for most models, this would be something like perhaps 
> an image and a couple of strings for an item. And these would only 
> need to live for a short time, because once the remove animation is 
> done, the data can be removed again.
>
> I think it is certainly worthwhile to investigate.

That's good.

I think we should really try to make sure there is no API needed to 
enable working behavior. 'Working' should be the default.

Thanks,

Steve.

-- 
Ableton AG, Schoenhauser Allee 6-7, 10119 Berlin, Germany
Management Board: Gerhard Behles, Jan Bohl
Chair of the Supervisory Board: Uwe Struck
Registered Office: Berlin, Amtsgericht Berlin-Charlottenburg, HRB 72838

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160121/977819d2/attachment.html>