Re: focus problem

[Fred Kiefer]

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.

Fred