Re: Fix for window flicks when getting focused

[Yen-Ju Chen]

On 9/5/07, Fred Kiefer <fredkiefer@gmx.de> wrote:
> 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?

  It can be the solution.
  Or to add another argument in -orderwindow:::
  to indicate the window to be ordered front is also the key window
  so that it will not use XGetInputFocus() to check key window.

  Yen-Ju

>
> Fred
>
>