(Ted & Katie suggested we move this discussion to the dev list...)
Hi Ted,
Sorry, I'd forgotten about this, and I'm not sure what to try to do for
0.6. Here's the history (by typing this out, I'm hoping I'll cover all
the issues!):
The detail view needs to get updated when something affecting its
current display changes elsewhere, including these use cases:
A. The user edits the item title in the summary view
B. The user drags the item to a different date/time in the calendar view
C. The user drags the item and drops it onto a different sidebar
collection
D. The user dismisses a reminder on an item; the "alarm" popup should
change to "None".
E. While viewing an item that's shared, the user does Sync All, and
receives a new version of the item with some of the attributes changed.
F. While viewing the second instance of a recurring event, the user
changes the "occurs" popup back to "once", whereupon the viewed instance
no longer exists.
It used to use a private collection, into which it would put the item
being displayed. This was good in that the DV found out about all the
cases, but John didn't like the extra collection, and I didn't like that
the notification was pretty coarse (any change resulted in one
notification, which caused us walk the DV block tree, reload all the
attribute editors, and relayout the sizers in case anyone's visibility
changed). Also, these notifications were asynchronous, meaning I
couldn't ignore the notifications caused by the DV's own changes to the
attributes of the displayed item: any change caused the DV to reload
itself entirely.
Earlier in 0.6, I switched to per-attribute repository Monitors, and
that's the way things are now: at Block.render time, each attribute
editor block queries the content model to find out what 'real'
attributes affect its presentation and/or visibility (for instance, the
end-time editor is affected by 'startTime', 'duration', 'allDay', and
'anyTime'), and creates a monitor on that attribute. at wxDestroyWindow
time (the converse of render), it discards the monitor.
This gave me notifications that were (a) synchronous and (b)
attribute-specific. However (and I didn't realize this at the time),
monitors don't fire when a change is "refreshed" into this repository
view from another view -- this broke use case E. Also, the monitor
doesn't fire when the entire item is deleted, breaking use case F. Also
also, Andi doesn't like this use of monitors for performance reasons
(nor do I: they call me anytime an attribute with the given name
changes, and my handler needs to filter out notifications on items other
than mine, which seems wasteful).
In the meantime, John developed a clever way to make asynchronous
notifications happen synchronously, by making attribute changes this way
(from a particular block that wants to ignore its own notifications):
- Deliver all pending notifications
- Increment a counter that, if non-zero, will cause my block's
notification handler to do nothing when it gets called
- Make the attribute change
- Deliver all pending notifications (the counter will cause my block's
notifications to be ignored, but other blocks will get theirs, which is
good)
- Decrement the counter.
Since cases E and F are currently broken, I'm faced with revisiting this
whole notification thing. I don't have a new strategy that covers
everything, though.
When I discuss it with John, he says you should make the
collection-notification mechanism work for individual items, but I don't
know how much work that is, and I'm not sure how to use it to get
per-attribute notifications (since we still don't want to reload the
entire detail view whenever a single attribute changes).
Nor whether I'll get the notification on item deletion for use case F...
but another solution for that might be for the detail view's trunk
parent block -- the block above the DV in the block hierarchy, which has
the responsibility for deciding what detail view tree-of-blocks to hang
underneath itself -- to take on the responsibility for handling the case
where the displayed item is deleted. It might be able to do this by
monitoring the collection of all items of the displayed item's Kind
(does such a collection exist?) - when a change notification on that
fires, it could see if the selected item was deleted, and if so, switch
to the None view. (It's possible, though, that Mimi would find this
jarring; I haven't asked what the desired behavior is here.)
So, in summary: I don't know what I need, or whether item notifications
will solve all my problems. What do you think, after reading all this?
...Bryan
Ted Leung wrote:
I just wanted to check in with you regarding bug 4269. Do you know
any more about
whether you are going to need suppport for this?
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
