Re: Fix for window flicks when getting focused

[Fred Kiefer]

Yen-Ju Chen wrote:
> On 9/4/07, Fred Kiefer <fredkiefer@gmx.de> wrote:
>> Yen-Ju Chen wrote:
>>> This patch tries to fix the GNUstep window flicks when it gets focus.
>>> This is the situation I traced:
>>> 1) A GNUstep window get focused.
>>> 2) [XGServerWindow orderwindow:::] receives NSWindowAbove with otherwin == 
>>> 0.
>>> 3) It uses XGetInputFocus() and it succeeds because there is one
>>> window has focus (may not be the GNUstep window).
>>> 4) The GNUstep window is actually lowered because NSWindowAbove
>>> becomes NSWindowBelow.
>>> 5) Later, this window get focused again and raise again.
>>>
>>> Due to step 4 and 5, the GNUstep window is lowered and raised in short time,
>>> which creates the flicks.
>>> The patch is not meant to be applied directly, but shows the problem.
>>>
>> I am not sure about your diagnostic here. When a window is clicked it
>> will first get key status and then will be ordered to front, which
>> should be fine. So you must be talking about another way to get focus.
>> Could you please explain about that?
> 
>   Say you have a xterm window partically cover a Ink.app window.
>   (xterm is the focused window and
>   Ink.app is inactive in this case since it is not focused.)
>   When user click on the Ink.app window,
>   Ink.app try to use XGetInputFocus() to find the key window,
>   which will return xterm window.
>   Then Ink.app will try to place its window under xterm first
>   because it thinks xterm is the key window.
>   So the fundamental problem is that it is not correct
>   to use XGetInputFocus() to find the key window.
>   XGetInputFocus() can return any window which may not belong to
>   the GNUstep applicaiton whose window is clicked by users.
> 
>> I would think that either the application is already active, then it
>> also has the focus and a key window or the application isn't active.
>> Then another application should have a key window and we should not
>> bring a window in front of that.
>>
>> Where is my reasoning wrong?
> 
>   In your second reasoning that application isn't active,
>   then user click on its window,
>   it may firstly try to -orderFront: its window and
>   get the wrong key window (see above).
>   If the application is alreayd active, there is no problem of flicking.
> 

When the application is not active and you click on a window two things
may happen.
Either you double click on the app icon window, this will bring all the
windows of the app to front and then activate it. THis case may be wrong.
On the other hand if you click on a normal window, this should result in
the window to become key and order front and then in the application to
activate itself. Is the problem here that the order front happens before
the setting of the focus (via make key) is properly finished? This would
explain, why your change make a difference.

And now I see that makeKeyAndOrderFront: does things the other way
around. It first orders front and then makes key. This is most likely so
to make sure the window is visible before making key. But this fully
explains the problem. How to resolve this? Should we introduce a new
interface to the backend to specify that a window will first be
displayed and then become key?

Fred