gnustep-dev
[Top][All Lists]
Advanced

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

Re: Changes to nextEventMatchingMask:


From: Richard Frith-Macdonald
Subject: Re: Changes to nextEventMatchingMask:
Date: Tue, 6 Oct 2009 09:34:12 +0100


On 5 Oct 2009, at 18:36, Fred Kiefer wrote:

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.

You have a good set of questions, but I'm not sure that the mailing list will help since I suspect nobody knows very much about these sort of internals ... certainly what I know I tend to forget. I'm aware that it's really tedious/slow to do it, but I think that generally the only reliable way to answer these sorts of things is to carefully design code to test the behavior on OSX and copy that behavior (even if it's not what the documentation would lead you to expect). Unfortunately I have no experience of writing GUI testcases which will work with our testsuite ... if we had such testcases we could run the testsuite on both OSX and GNUstep to see how we compare with the 'reference' implementation (I do that with the base library tests occasionally).

I don't recall whether you have an OSX machine available ... if not, I can certainly run tests for you.

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

Just a gut feeling, but setting the current event when we are only peeking seems wrong. I think I'd need to check the source to find out *when* we peek and what we do with the results of peeking though.

- 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?

I suspect that it should never be returned.

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

That sounds like a simple bug ... but fixing it might reveal bugs elsewhere.

- 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?

Now this one I have a vague memory of ... I think I may have made the code operate this way because it appeared to be the OSX behavior to update the window on entering an event loop (ie before retrieving the first event). That way, the windows are up to date at the point where we start blocking, waiting for an event.

- 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?

It sounds right to me.





reply via email to

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