bug-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: focus problems [PATCH]


From: Benhur Stein
Subject: Re: focus problems [PATCH]
Date: Fri, 17 Oct 2003 12:49:54 -0200

On 2003-10-16 20:01:53 -0200 Adam Fedor <address@hidden> 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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]