On 8/28/07, Yen-Ju Chen <[EMAIL PROTECTED]> wrote: > On 8/28/07, Fred Kiefer <[EMAIL PROTECTED]> wrote: > > Yen-Ju Chen wrote: > > > 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. > > > > > > > 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. > > Thanx. I will take a look.
It seems to fix the problem. Yen-Ju > > > > > Anybody an idea how to detect a miniaturize from X windows? > > > > In Azalea, miniaturization is the same as iconification, > which basically unmap the window, > and the implementation says: > > /* According to the ICCCM (sec 4.1.3.1) when a window is not visible, it > needs to be in IconicState. This includes when it is on another > desktop! > */ > > So the "WM_STATE" property is changed to IconicState when minimized. > I don't know how GNOME and KDE window manager deal with minimization. > > If it does not fit what GNUstep want, > a private protocol should be fine as what WindowMaker does, > as long as it is documented at some place, ex, GNUstep wiki: > http://wiki.gnustep.org/index.php/Window_manager > > Yen-Ju > _______________________________________________ Etoile-discuss mailing list [email protected] https://mail.gna.org/listinfo/etoile-discuss
