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
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
