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: Tue, 4 Sep 2007 20:19:56 -0700

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.

  Yen-Ju

>
> Fred
>




reply via email to

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