Re: focus problem

[Yen-Ju Chen]

On 8/29/07, Yen-Ju Chen <yjchenx@gmail.com> wrote:
> 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

  For minimization, I can add "_GNUSTEP_WM_MINIATURIZE_WINDOW" atom in Azalea.
  It is just another GNUstep-specific atom for window manager.
  It would also be nice that GNUstep can remove the check for
  WindowMaker (XGServerWindow.m, line 813 and 1960) for that atom
  so that other window manager can know
  GNUstep window support this minimization atom.

  I also notice that when last document window has modification
  and user tries to close it and an alert window shows up,
  if users select "don't save", both alert window and last document window
  will be closed and the application will become inactive (menu disappears).
  But interestingly, if I move the last document window first
  before closing it, it will be fine (main menu stay).
  I don't know where is the problem yet (GNUstep or window manager).

  Yen-Ju

> >
> >   Yen-Ju
> >
>