[Dev] Bug 4269 and detail view notifications, again

[Bryan Stearns]

(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?