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