Re: focus problems [PATCH]

[Benhur Stein]

On 2003-10-16 20:01:53 -0200 Adam Fedor <fedor@doc.com> wrote:
> Focus problems are my nemesis so perhaps I can ask a few questions. 
> I
> need to try to document all the problems and what's been tried to 
> fix
> them
You are right, sorry for not documenting them.

> > +++ Source/x11/XGServerEvent.m  15 Oct 2003 17:10:45 -0000
> > @@ -528,6 +528,8 @@
> >                           number = generic.currentFocusWindow;
> >                         [self setinputstate: GSTitleBarKey : 
> > number];
> >                         [self setinputfocus: number];
> > +                       generic.focusRequestNumber = 0;
> > +                       generic.desiredFocusWindow = 0;
>
> Why does this cause a problem for you? You can read the comment 
> above
> this in the source about some of the problems this solves, although
> there are others it solves as well.
The problem is the focus going to the wrong window sometimes. For 
example:
open 2 windows of one application (say Terminal) and one window of 
another
(say GWorkspace). Then do the following:
- select one of Terminal's windows as key
- select GWorkspace's window as key
- select the other terminal window, focus go to the previously 
selected
  one instead of the clicked window.

How I understand the existing code:
The event that is being processed in this method is generated when 
the
window manager is telling us to take focus in some window. From what 
I
could gather, this can happen at least in two circumstances:
- we had previously asked the WM to give focus to the window
- some external event (the user clicking on the window, for example,
  (which should be accepted) but also some other cases (when we
  should not accept the focus))
To know if we should accept the focus or not there is this 
desiredFocusWindow
variable, that is set each time setinputfocus is called, that asks 
the WM
to give focus to some window. setinputfocus can be called from gui, 
in which
case we want to make sure the right window is selected, hence the 
use of
this variable. But when setinputfocus is called in response for an 
event
generated in WM (that is the case here), it should not keep 
desiredFocusWindow
set, because it prevents further events generated by the WM (user 
clicking
on the window, for example) from changind the focused window.
This patch (tries to) solve the problem.
Maybe the whole desiredFocusWindow mechanism should be reviewed..

> +++ Source/NSApplication.m      15 Oct 2003 17:17:59 -0000
> @@ -949,8 +949,13 @@
>         }
>        else if ([self mainWindow] != nil)
>         {
> -         [[self mainWindow] orderFront: self];
> +         [[self mainWindow] makeKeyAndOrderFront: self];
>         }
>
> Why this? We don't really want to make the main window key unless 
> it is
> supposed to be?
Yes, but if the application had a key window, it would have been 
selected in the
previous 'if'. If it doesn't have a key window and one is not set, 
the application
will not be focused and the previously selected application will 
remain with the
focus, and the window being activated here will not really be 
activated. The menus
of both applications will remain onscreen and it is the previously 
activated window that
will receive keyboard events.

> +      else
> +        {
> +         //FIXME: why doesn't this work?
> +          [[[self mainMenu] window] makeKeyAndOrderFront:self];
> +        }
>
> Did this not work before?  It works for me - WindowMaker tries to 
> give
> windows keyboard focus and the main menu should accept it (That's a
> hack, but it should work, see the WindowFocus documentation in
> back/Documentation/Back).

In most cases it works, but here it is the else of the two previous 
if's,
and it means that we are activating an application that does not
have a key nor a main window. For example, when launching an 
application
that has no windows. It menu should be selected as key so that the 
following
keyboard events go to the newly activated window. I didn't have the 
time
to find out why this code does not work, the mainmenu's window is 
onscreen,
it executes makeKeyAndOrderFront: but it does not get the key status.

To see the problem: In Terminal, do openapp Affiche (for example)
When Affiche's menu appears, Terminal's remain onscreen. Type 
Command-n
and you get a new terminal window instead of a new Affiche note.

The other focus problem I have is with this newly created Terminal 
window,
it has the input focus, bu if I start typing it shows strange chars, 
like when
i type with right-alt pressed. I must click on the window's title 
before
typing, and it is very annoying, it gets me most of the times.

Is it only me who is having this weird focus behaviour?

Cheers,
Benhur