Thanks Bryan -- yes, this is helpful.
Yes, I think we should proceed with your suggestion of using the private
item collection to notice the delete case, for 0.6.
If we can get by with not fixing case E (which I think we can), we have
a relatively small/safe fix for F, and we don't see monitors as blocking
our performance use cases from hitting "acceptable" times, then we
should avoid the per-item notification work for 0.6.
Cheers,
Katie
Bryan Stearns wrote:
OK, so as I understand it, per-item notification isn't planned for 0.6
(it will "go on the list [for 0.7] if it doesn't make it on 0.6").
Until it does, I think we should leave monitor-based notifications on
individual attribute editors as they are, and not worry about bugs
relating to changes arriving from other views (ie, via sync - this was
use case E in my original message).
That leaves whether (and how) to fix use case F (user changes a
non-first occurrence of a recurring event to 'once', thus deleting the
displayed item); the primary way we've talked about this is to use a
private item collection (off the branch-point/trunk-parent block right
above the DV), and use its notification to find out when the item is
deleted. I think this is small and safe enough to do for 0.6.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
