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

Tue Nov 1 15:00:18 PST 2005

Katie Capps Parlante wrote:

> I said: take the discussion to the list, because Bryan's writeup is 
> informative and the ensuing conversation will help me get more 
> information to make a good judement. ;)
>
> It sounds like per item notification is something we should do in the 
> long term -- at least in 0.7.
>
> I'm taking Ted's comment seriously that tweaking this in 0.6 is a bit 
> risky. Ted: is that just a guess at this point? Is it worth going down 
> the path of implementing it to see if it really pans out as risky? 
> Could we allocate real time to functional tests to mitigate the risk?
>
> I'm also interested in whether or not we know that the current monitor 
> implementation is impacting performance as suspected. Is this showing 
> up in any of our performance use cases?

My understanding is that monitors alone won't work because they won't 
notify you of changes that come in as changes from other repository views.

>
> Cheers,
> Katie
>
> John Anderson wrote:
>
>> 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
>>
>>
>>
>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>
>> Open Source Applications Foundation "Dev" mailing list
>> http://lists.osafoundation.org/mailman/listinfo/dev
>
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/dev