[Kde-pim] Re: Review Request: Include collections wich are watched in the ChangeRecorder in the EntityTreeModel
Christian Mollekopf
chrigi_1 at fastmail.fm
Tue Jan 25 12:24:56 GMT 2011
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://svn.reviewboard.kde.org/r/6330/
-----------------------------------------------------------
(Updated Jan. 25, 2011, 12:24 p.m.)
Review request for KDE PIM, Volker Krause, Stephen Kelly, and Tobias Koenig.
Changes
-------
After the last versions, which only affected the entitytreemodel, I noticed that notifications are not sent by the monitor for subcollections of explicitly monitored collections, although stated otherwise in the apidox.
Therefore this patch affects both the monitor and the entitytreemodel. As only the entitytreemodelpatch relies on the changes in the monitor, you can ignore the entitytreemodel part if you want.
The patch is however work in progress, but it is almost fully working in the cases i tested.
So all I need to know is, if I'm going in the right direction.
Of course also any comments on the implementation are more than welcome.
Thanks
Summary (updated)
-------
Monitor part:
Currently the monitor does not emit notifications for subcollections of explicitly monitored collections (although stated otherwise in the apidox).
A special case is when Collection::root is watched, where notifiactions for all items are emitted.
With this patch, the monitor properly emits notifications for all subcollections of an explicitly monitored collection (when enabled by the additional parameter).
This is implemented by finding implicitly watched collections (subcollections of an explicitly watched collections), and storing them in an additional list.
The other option would be to have all parent collections of the collection in question available, so we could check in the isCollectionMonitored() call, if a parent is explicitly monitored.
Following changes are visible from outside:
-When subcollection monitoring is enabled, the collectionMonitored() signal is delayed until all subcollections are available.
-When subcollection monitoring is enabled, the collectionsMonitored(true) list contains also the implictly monitored collecitons
With the default parameters, the monitor should behave exactly the same. Also this should only affect the behaviour when collections are explicitly monitored.
If resources are monitored, nothing changes.
The change is not binary compatible atm, so I will have to fix this.
Also the new mapping is atm not updated if the collection changes (i.e. new mime type), which leads to some problems.
I just need to know, if I'm going in the right direction. If yes I will polish it and create a separate review request only concerning the monitor.
EntityTreeModel part:
Instead of recursivly fetching explictly monitored collections, we rely on the new collectionsMonitored(true) list, which included all implcitly monitored subcollections.
This ensures that we only have collections in the model, for which we also receive the change signals.
There are still some glitches, but is this generally ok, or completely off the track?
Diffs (updated)
-----
/trunk/KDE/kdepimlibs/akonadi/monitor.h 1216830
/trunk/KDE/kdepimlibs/akonadi/monitor.cpp 1216830
/trunk/KDE/kdepimlibs/akonadi/monitor_p.h 1216830
/trunk/KDE/kdepimlibs/akonadi/monitor_p.cpp 1216830
/trunk/KDE/kdepimlibs/akonadi/entitytreemodel.h 1216830
/trunk/KDE/kdepimlibs/akonadi/entitytreemodel_p.h 1216830
/trunk/KDE/kdepimlibs/akonadi/entitytreemodel_p.cpp 1216830
Diff: http://svn.reviewboard.kde.org/r/6330/diff
Testing (updated)
-------
Thanks,
Christian
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/
More information about the kde-pim
mailing list