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