Yen-Ju Chen wrote: > On 8/22/07, Yen-Ju Chen <[EMAIL PROTECTED]> wrote: >> On 8/22/07, Fred Kiefer <[EMAIL PROTECTED]> wrote: >>> >>> Yen-Ju Chen wrote: >>>> On 8/22/07, Fred Kiefer <[EMAIL PROTECTED]> 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 _______________________________________________ Etoile-discuss mailing list [email protected] https://mail.gna.org/listinfo/etoile-discuss
