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