I just switched the implementation of NSWindow setFrame:display:animate:
over to using an NSViewAnimation. The reason for this was that the old
blocking code could yield wrong results as intermediate setFrame: events
send from the backend would not be processed during the animation and at
the end the window could end up in a messed state.
With NSViewAnimation I first had the problem that this code was not
prepared to ever release an NSViewAnimation, this was easy to fix, still
I needed a helper object that will release the animation when it ends. I
was hoping that I could release the animation after starting it and then
rely on it to free itself up when it gets stopped. But this wont work
with our current code in NSAnimation and with all the lock handling
scattered in there I did not dare to change anything.
With my helper object things basically work, although I am not sure that
in a garbage collected environment the same will be true.
Not there is one remaining problem. When I start the animation it
registers an NSTimer itself for the run modes NSDefaultRunLoopMode,
NSModalPanelRunLoopMode and NSEventTrackingRunLoopMode. When the
animation gets stopped the timer gets invalidated and will be removed
from the corresponding run loops later on. But as there is no
NSModalPanelRunLoopMode going on in my test application it never gets
removed from that list and I end up with all these timers living
forever. Not that I care much, even a few hundred timers shouldn't stop
that application from working, still it looks wrong to me.
_______________________________________________
Gnustep-dev mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/gnustep-dev
