discuss-gnustep
[Top][All Lists]
Advanced

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

Re: focus problem


From: Yen-Ju Chen
Subject: Re: focus problem
Date: Thu, 23 Aug 2007 08:55:01 -0700

On 8/23/07, Fred Kiefer <fredkiefer@gmx.de> wrote:
> Fred Kiefer wrote:
> > Yen-Ju Chen wrote:
> >> On 8/22/07, Yen-Ju Chen <yjchenx@gmail.com> wrote:
> >>> On 8/22/07, Fred Kiefer <fredkiefer@gmx.de> wrote:
> >>>> Yen-Ju Chen wrote:
> >>>>> On 8/22/07, Fred Kiefer <fredkiefer@gmx.de> wrote:
> >>>>>> Let me try to reduce the amount of confusion in this
> >>>>>> discussion. There are multiple issues with focus setting in
> >>>>>> GNUstep and Yen-Ju and Andreas are talking about to
> >>>>>> completely different ones. Andreas has a problem when
> >>>>>> switching between applications via DO. This should be fixed
> >>>>>> by my latest change to SVN, but this change introduced a well
> >>>>>> known race condition when clicking on slow responding
> >>>>>> applications. Richard and I will be looking into this some
> >>>>>> more. Yen-Ju is concerned about the focus loss of an
> >>>>>> application when the last window is closed. His different
> >>>>>> patches try to solve this. As for the last patch I am a bit
> >>>>>> surprised that it changes anything. We have similar code
> >>>>>> already in [NSWindow _lossOfKeyOrMainWindow]. The main
> >>>>>> difference I see here is that Yen-Ju's code doesn't check if
> >>>>>> the ordered out window was key before. But why would we have
> >>>>>> to change the focus when the window being closed wasn't key?
> >>>>>> The patch may still be valid, I just don't understand it.
> >>>>> The _lostOfKeyOrMainWindow is not called when window is closed.
> >>>>>  When the last document window is closed, it first receives the
> >>>>> UnmapNotify, then FocusOut. When FocusOut comes, GNUstep looks
> >>>>> for where the focus is. But at the same time, window manager
> >>>>> may not prepare the focus yet. So GNUstep cannot find focus on
> >>>>> its own window, then deactivate. As in one of my previous
> >>>>> patch, which use usleep() to wait 1 second between FocusOut and
> >>>>> looking for focused window (XGetInputFocus) in backend, it
> >>>>> works fine. So the race is between when window manager
> >>>>> transfers the focus and when GNUstep uses XGetInputFocus to get
> >>>>> the focused window. To solve this racing issue, GNUstep can
> >>>>> transfer focus before the window is closed or window manager
> >>>>> can do that. No matter which party does so, the correct
> >>>>> sequence would be: 1. last document window received a close
> >>>>> action. 2. transfer focus to another window. Since it is the
> >>>>> last document, it can only transfer to main menu. 3. last
> >>>>> document window receive UnmapNotify. 4. last document window
> >>>>> receive FocusOut and check where the current focus is. Since
> >>>>> the focus is probably on main menu already, it will not
> >>>>> deactivate.
> >>>>>
> >>>>> Without step (2), step (4) will deactive the GNUstep
> >>>>> application. Since GNUstep knows better about where the focus
> >>>>> should go, I believe it may be easier to do step (2) in
> >>>>> GNUstep.
> >>>>>
> >>>> If the window manager closes the window without telling GNUstep,
> >>>> then we really have a problem, but when it goes via [NSWindow
> >>>> close] as your patch suggest then the next method called will be
> >>>> [NSWindow orderOut:], which in turn calls [NSWindow
> >>>> orderWindow:relativeTo:]. Here we call [NSWindow
> >>>> _lossOfKeyOrMainWindow] for the NSWindowOut case. That is why I
> >>>> thought your patch shouldn't change things to much.
> >>> I notice the [NSApp keyWindow] is not correct. That's why
> >>> _lossKeyAndMainWindow does not work properly. I am still looking
> >>> into the problem.
> >> Here is the trace I have:
> >>
> >> (1) In NSWindow -close, it posts NSWindowWillCloseNotification. (2)
> >> in NSApplication, _windowWillClose: is called, which resigned key
> >> window. At this point, there is no key and main window, but main menu
> >>  and app icon. (3). Window is order out, and _lossKeyAndMainWindow
> >> does nothing because there is no key window. (4) Neither main menu
> >> and app icon gets focus at this point, so when it receive FocusOut,
> >> it deactives itself.
> >>
> >> Does it make sense ?
> >>
> >
> > Yes, it does! Thank you for digging so deep into this. It now turns out
> > that we don't have to little code for the focus handling but too much.
> > I have a closer look at the code in NSApplication, but most likely this
> > should go. Perhaps we could even try to have just one method that
> > handles the search for a new key window? This would make things easier
> > the next time we have a problem in this area.
> >
>
> I started to implement a solution for this problem, but as I am not
> using GNUstep window decoration I have the additional problem that my
> windows don't get notified when they are closed or miniaturized. I will
> have to resolve that issue first.
> I am away from now on until next Tuesday if anybody needs a solution
> before that time, they will have to implement it themselves :-)
>

  Glad we found the source of problem.
  I am not using GNUstep window decoration, either,
  but NSWindow does receive -close when it is closed.
  Window manager should send a WM_DELETE_WINDOW event for closing window.
  I don't know the minimature yet,
  it may depends on the implementatin of window manager.

  Yen-Ju

> Fred
>




reply via email to

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