[Dev] Problem with collection notifications
john at osafoundation.org
Sat Sep 24 14:03:50 PDT 2005
Phillip J. Eby wrote:
> At 10:30 AM 9/24/2005 -0700, John Anderson wrote:
>> In many cases, for example when updating the UI, we change data which
>> will eventually cause a notification,
> Why is the UI changing data? Do you mean that it's changing blocks,
> or do you mean that user data is actually being changed? If the UI is
> changing any data other than UI objects, we need to fix it or at least
> have a plan for how we're going to fix it.
UI state is persisted in the block. After all, in the MVC paradigm for
UI, the block is the model and the widget is the view. When the widget
tells us of a change like the position or state of a window, we need to
store it in the block and typically the UI is already up to date so
there is no need for a notication.
Here are two situations. I'm sure there are more:
Clicking changes the selection and the selection is persisted in a
block. A notification is unnecessary, since the screen is already up to
date. Dragging an item in the calendar has the same effect.
Clicking in the sidebar changes the order of the collections that make
up the collection that's displayed in the Calendar. That changes a
collection that causes the sidebar to redraw. The redraw is unnecessary
> If it's just that you're receiving notifications about changes to the
> UI objects, then we need to investigate why either:
> 1. notifications are being issued even when the data hasn't actually
> been changed, or
> 2. the UI is changing data in a way that doesn't converge to a fixed
> point (where no further changes are needed)
> In short: none of the three ways I can think of to interpret your
> comments require temporarily ignoring notifications, because all three
> indicate that there is a bug in some part of the system. Either the
> UI is broken (updating data it shouldn't be, or updating in a
> non-convergent way) or notifications themselves are broken (issuing
> redundant notifications for unchanged values).
The more I think about it the more I'm convinced that the only real
solution is synchronous notifications.
> In the simplest case, notifications shouldn't be issued if you set
> some attribute to a value it already has. There are more complex
> cases that can produce an end result of "not changed" even though
> there were intermediate changes, and I'm pretty sure nobody's coded up
> those cases, even if the "set to the same value" case is taken care
> of. We need to find out which case is causing your problems, though.
> So, in summary, it shouldn't be *necessary* to suppress notifications
> to work around a bug (or missing feature) in notifications, nor should
> it be *allowed* to suppress notifications in order to get away with
> doing things that shouldn't be being done, like modifying user data
> from UI code in response to notifications, or modifying UI data
More information about the Dev