[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
> >
> >
>