Re: NSWindow receives NSAppKitDefined/GSAppKitWindowMoved strange messages with x = -1

[Philippe Roussel]

Le 04/05/2012 00:21, Fred Kiefer a écrit :
> On 30.04.2012 19:39, Philippe Roussel wrote:
>> Le 30/04/2012 18:16, Philippe Roussel a écrit :
>>> Le 30/04/2012 17:03, Fred Kiefer a écrit :
>>>> 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.
>>
>> The following minimal patch/hack works for me without any visible bad
>> consequences.
>>
>> I'm still having problems when closing and reopening the preferences
>> panel without exiting the application (sometimes the panel wrongly
>> appears in the top left corner and with a bad size) but it doesn't seem
>> related. I'll try to dig further.
> 
> Most likely all this is related. In my new daytime job I am now using
> Unity as the window manager and have a somewhat better understanding of
> how this interferes with all windows. In some cases this is rather nice
> and gives an almost Mac like feeling, but in many cases it makes
> applications unusable. I haven't tried GNUstep in that environment, but
> I can imagine a lot of things that could go wrong there.
> 
> I think that normally we don't want to ignore resizes that happen while
> a window is invisible, but for Unity this may be the case. We have the
> extra case of NSAppKitDefined events that get handled even when a window
> is invisible in the [NSWindow sendEvent:] method and I think in most
> cases this is correct. You could change this as a test, but there is no
> guarantee then, that the window manager and the GNUstep application
> agree on where the window is positioned when it is made visible again.
> Due to our current code in [NSWindow orderWindow:relativeTo:] this wont
> do any harm for titled windows, but windows with out a title might be
> displayed at the wrong place.

Changing the code in sendEvent: from

if (!_f.visible && [theEvent type] != NSAppKitDefined)

to

if (!_f.visible)

seems to change a lot of things. The appicon isn't correctly displayed
for example but I didn't try to understand why.

I've observed other strange behaviours with newer window managers
(unity, gnome-shell, recent metacity). For example, a window with
NSStatusWindowLevel has no decorations and cannot be moved, contrary to
what happens with windowmaker. There might some work to do to support
those wms...

Thanks,
Philippe