[Dev] Re: Bug 4269 and detail view notifications, again

Tue Nov 1 14:29:14 PST 2005

Hi Ted:

When we talked about this awhile ago I suggested you ask Katie her 
opinion on where to fit it in the schedule. Do you remember what she 
said? I can think of a bunch of cases where it would be really handy to 
get notifications on items.

John

Ted Leung wrote:

>
> On Nov 1, 2005, at 12:59 PM, Bryan Stearns wrote:
>
>> (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).
>
>
> In principle I'm not opposed to having notifications for individual  
> items.  It's not there because we never talked about this as a  
> possible use case.   I have some ideas about how to make this work,  
> but I am concerned about trying to implement them for 0.6.    Making  
> this work is likely going to require rearranging the guts of  
> notification, which may have impacts on other parts of the system.    
> Since we are testing the UI by hand, it might be some time before we  
> could find any subtle bugs introduced by changes at this late a  
> date.     I also believe that I know how to make the changes to allow  
> notifications to tell what attribute(s) of an item have changed  
> instead of just that the entire item has changed.
>
>>
>> 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?
>
>
> In my mind it all comes down to how much risk we are willing to take  
> for 0.6.  Trying a private collection, while ugly is likely to have  
> fewer effects on the entire system.   If that doesn't work, then we'd  
> have to implement per item notification, and hope that we don't  
> introduce any subtle bugs.    In the long term, per item notification  
> is something that we should probably do.   Also long term, we really  
> need to increase our functional/GUI test coverage so that we can have  
> more confidence to make these kinds of changes.   More on that in  
> another post.
>
> ----
> Ted Leung                 Open Source Applications Foundation (OSAF)
> PGP Fingerprint: 1003 7870 251F FA71 A59A  CEE3 BEBA 2B87 F5FC 4B42
>
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/dev