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.
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).
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
