Re: NSWindow retains cycle

[Nicola Pero]

Hi - thanks - good point ... which made me think.

Why are we hijacking the keyUp: and trying to send it to the view which
originally got the keyDown: ?  Wouldn't it be more simple and natural to
send it to the current first responder ?  I couldn't find in the doc any
reference to this behaviour we are trying to implement.  Can someone on
MacOSX try and let me know ?  We might try to send it to the original
first responder if that helps compatibility, but otherwise ...

I mean, if you do the following - 

 mouse-click on a view so that it is the first responder.
 press a keyboard key in it - keep the key pressed.
 move to the mouse to another view (while still keeping the key pressed).
 mouse-click on this new view, making it the first responder.
 release the keyboard key.

Does the keyUp: go to the first view or to the second view ?  Can someone
with MacOS X test this ?

And what happens if the second view is in another window ?  In this case,
I don't see how we can send the keyUp: to the original view, since the
event is queued in a completely different window !  

Even harder - what happens if the user switches to another (possibly
non-gnustep) application while still holding down the key ?  The keyUp:
would never be sent to the original view simply because it's queued to a
third-party application.

So, any view waiting for a keyUp: after a keyDown: must anyway be prepared
to manage the case that it will never receive the keyUp: because the user
has switched to a different window/application ...

In general I don't see a particular problem in sending the keyUp: to the
second view ... I assume the idea is that the first view might be waiting
for the keyUp: ...

but in that case the first view would possibly start a modal loop scanning
events (the same as it happens to views when they track the mouse after a
mouseDown:, waiting for the mouseUp:), or just detect when it looses first
responder status, and if it has not yet got the keyUp:, assume it will
never get it. (the user might be releasing the key in another view or in
another window or in another application).

If anyone has any ideas/suggestions/comments/knows how it works on macos x
or - even better - how it worked on nextstep - please let me know ... I'm
inclined to completely remove the original first responder code but I'd
like to hear any opinion against this change first.


> Hi,
> 
> Another one, in NSWindow this time. The reason I wasn't seeing the
> previous bug every time was that an NSWindow will retain itself in
> NSWindow -sendEvent: when handling NSKeyDown if _firstResponder==self.
> In my case the key down went to a button that closed the window, so if
> the key up event arrived after the window disappeared (eg. if you hold
> down the key) the window won't get the event and it won't release
> itself.
> 
> Anyway, I think (it fixed the problem, at least) the way to fix this is
> to not retain/release _originalResponder if it's set to self. I've
> included a patch that does this.
> 
> [Incidentally, I've written a (really crude and ugly and i386-specific)
> retain/release/autorelease tracker that I've used when debugging it.
> Basically, it dumps a log of all retains etc. for objects you're
> interested in, and after it's done it's easy (but boring; it could be
> mostly automated) to sit down and match retains to releases and figure
> out where the problem is. If there's any interest I could upload the
> source somewhere. However, it is _really_ ugly.]
> 
> - Alexander Malmberg
> 
> Index: NSWindow.m
> ===================================================================
> RCS file: /cvsroot/gnustep/gnustep/core/gui/Source/NSWindow.m,v
> retrieving revision 1.217
> diff -u -r1.217 NSWindow.m
> --- NSWindow.m  18 Feb 2002 12:10:06 -0000      1.217
> +++ NSWindow.m  18 Feb 2002 16:46:56 -0000
> @@ -614,7 +614,8 @@
>    TEST_RELEASE(_windowTitle);
>    TEST_RELEASE(_rectsBeingDrawn);
>    TEST_RELEASE(_initialFirstResponder);
> -  TEST_RELEASE(_originalResponder);
> +  if (_originalResponder != self)
> +    TEST_RELEASE(_originalResponder);
>    TEST_RELEASE(_defaultButtonCell);
>  
>    /*
> @@ -2780,7 +2781,10 @@
>          * Save the first responder so that the key up goes to it and
> not a
>          * possible new first responder.
>          */
> -       ASSIGN(_originalResponder, _firstResponder);
> +       if (_firstResponder == self)
> +         _originalResponder = self;
> +       else
> +         ASSIGN(_originalResponder, _firstResponder);
>         [_firstResponder keyDown: theEvent];
>         break;
>  
> @@ -2790,7 +2794,10 @@
>            */
>           if (_originalResponder)
>             [_originalResponder keyUp: theEvent];
> -         DESTROY(_originalResponder);
> +         if (_originalResponder == self)
> +           _originalResponder = nil;
> +         else
> +           DESTROY(_originalResponder);
>           break;
>  
>        case NSFlagsChanged:                               // Flags
> changed
> 
> _______________________________________________
> Discuss-gnustep mailing list
> Discuss-gnustep@gnu.org
> http://mail.gnu.org/mailman/listinfo/discuss-gnustep
>