Changes to nextEventMatchingMask:

[Fred Kiefer]

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
Gnustep-dev@...
http://lists.gnu.org/mailman/listinfo/gnustep-dev

[Richard Frith-Macdonald-2]

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.



_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@...
http://lists.gnu.org/mailman/listinfo/gnustep-dev