discuss-gnustep
[Top][All Lists]
Advanced

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

Re: NSWindow receives NSAppKitDefined/GSAppKitWindowMoved strange messag


From: Philippe Roussel
Subject: Re: NSWindow receives NSAppKitDefined/GSAppKitWindowMoved strange messages with x = -1
Date: Mon, 30 Apr 2012 18:16:46 +0200
User-agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120329 Thunderbird/11.0.1

Le 30/04/2012 17:03, Fred Kiefer a écrit :
> On 28.04.2012 23:26, Philippe Roussel wrote:
>> Le 28/04/2012 00:08, Fred Kiefer a écrit :
>>> Thank you for running this analysis. It looks like the
>>> XTranslateCoordinates call produces incorrect results. I don't have the
>>> time to look into this until early next week. Perhaps you are able to
>>> find out what goes wrong in line 853 yourself until then.
>>
>> As I have zero experience with X, here's some more data. The 3 attached
>> files contain the result of the same action (close the preferences
>> panel) with GNU-Debug=NSEvent under unity, windowmaker and blackbox,
>> with the following debug patch applied.
>>
>> The bug only happens under unity, which is clearly doing a lot more work
>> and using rarely used code paths in gnustep back. Maybe being a
>> compositing manager explains all this.
>>
>> One thing I don't understand is why  we are reacting to ConfigureNotify
>> and sending NSEvents even when the window is not visible. Just adding a
>> test on cWin->map_state == IsViewable like below 'fixes' the bug for me.
>>
>> Anyway, XTranslateCoordinates returns 0 for x and y (no idea why)
>> _XFrameToOSFrame: substract 1 for the window border and voila, x = -1. I
>> tried checking XTranslateCoordinates return value but there are no
>> errors.
> 
> Not handling move and reparenting events when the window is not visible
> sounds like a great idea to me. The only problem is that we would need
> to test this with each and every window manager that we support :-(
> 
> A saver solution might be to just not save the window frame in the event
> handling code of NSWindow, when the window isn't visible. Could you
> please test this and report back the results?
> It definitely isn't a complete solutions, as the stored frame will be
> wrong as long as the window isn't visible, but we could get away with a
> lot less testing.

I will test this tonight and report back.

Philippe



reply via email to

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