Re: focus problem

[Fred Kiefer]

Yen-Ju Chen wrote:
> 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.
> 

Yes, for close this event gets send from EWHM window managers, but there
is nothing corresponding for the miniaturize event, except for
WindowMaker. I just submitted some code changes to SVN that should
improve this focus problem, but the case of miniaturize is still handled
wrongly, just for this reason.

Anybody an idea how to detect a miniaturize from X windows?