gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Changes to nextEventMatchingMask:


From: Fred Kiefer
Subject: Changes to nextEventMatchingMask:
Date: Mon, 05 Oct 2009 19:36:42 +0200
User-agent: Thunderbird 2.0.0.23 (X11/20090817)

Nikolaus Schaller suggested to change the handling of updateWindows in
nextEventMatchingMask:... of NSApplication to redraw less often. This
made me aware that I am not really familiar with the code there and I
would like to discuss a few issues on this mailing list.

- Setting the current event
When should we set the current event instance variable? Even when we
just peek for the next event?

- Consistency
At a few places in NSApplication we call DPS functions to get events
directly, this could lead to a few inconsistencies, but perhaps it does
exactly what we want. For example we only set the current event, when it
matches the modal window.

- null_event
We use an internal null_event to stop the event loop, should
nextEventMatchingMask:... ever return that or silently discard it and
return nil, even when waiting for an event until the distant future?

- modal loop
The modal loop methods currently uses NSDefaultRunLoopMode, where they
should be using NSModalPanelRunLoopMode.

- updateWindows
Currently we call updateWindows as the first thing in this method. The
documentation suggests that it should be called after each event in the
main loop. But isn't before getting a new event the same as after
processing the last one? What if we don't call nextEventMatchingMask:...
for a long time?

- NSEventTrackingRunLoopMode
For this mode updateWindows should not be called automatically. What we
do is not setting the flag to call it the next time this method is
invoked. That way we still update the windows when they are actually
changed. Is this what is needed?





reply via email to

[Prev in Thread] Current Thread [Next in Thread]