discuss-gnustep
[Top][All Lists]
Advanced

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

Re: Fix for window flicks when getting focused


From: Yen-Ju Chen
Subject: Re: Fix for window flicks when getting focused
Date: Thu, 6 Sep 2007 23:19:36 -0700

On 9/5/07, Yen-Ju Chen <yjchenx@gmail.com> wrote:
> 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.

This is the current implementation of makeKeyAndOrderFront:

- (void) makeKeyAndOrderFront: (id)sender
{
  [self orderFront: sender];
  [self makeKeyWindow];
  /*
   * OPENSTEP makes a window the main window when it makes it the key window.
   * So we do the same (though the documentation doesn't mention it).
   */
  [self makeMainWindow];
}

Would it make sense to use -orderFrontRegardless instead of -orderFront: ?
By looking at the source code, it may solve the problem.
I haven't test it, though.

Yen-Ju

>
>   Yen-Ju
>
> >
> > Fred
> >
> >
>




reply via email to

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