Re: focus problem

[Fred Kiefer]

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 :-)

Fred