Re: focus problem

[Yen-Ju Chen]

On 8/28/07, Yen-Ju Chen <yjchenx@gmail.com> wrote:
> On 8/28/07, Fred Kiefer <fredkiefer@gmx.de> wrote:
> > 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.
>
>   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
>