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