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? _______________________________________________ Gnustep-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnustep-dev
