A situation often occurs when updating the
summary/sidebar/calendar/detail views in which you're responding to a
user event, e.g. mouse or key event. Your event handler needs to change
some data, e.g. move or delete an event then update the screen. After
you've finished updating the screen we fall through to the idle loop
where notifications are generated that tell you the data displayed in
your view has changed. This causes another unnecessary complete redraw
of your view -- which makes Chandler feel much slower than it really is.
To avoid this problem you should bracket your event handler/update code
with calls to new routines on your block (stopNotificationDirt and
startNotificationDirt) which will ignore notifications that dirty your
block during the event handler. Make sure that after calling
stopNotificationDirt you put all your update code in a try block which
has a finally block containing the startNotificationDirt, so that it
gets called even if an exception occurs.
I've already implemented this in Table, which is used in the Sidebar and
Summary View and it made a big difference, so I suspect it could also
make a big difference in the Calendar View.
John
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
