Version: $Revision$
Date: $Date$
This document describes how various system and user actions affect window focus of GNUstep applications. This document describes focus changes that occur outside of application control, since application focus changes are well described in the class documentation.
The application can get focus in several ways.
The first case does not directly affect window focus (because there are no windows at startup). However, as the application begins to create an order front windows (including the main menu) there will likely be a cascade of focus events generated by the window manager.
In the second and third case, the window manager will likely try to give focus to the window that previously had it or perhaps to some random window based on some internal window manager code. GNUstep may ignore this and try to give focus to another window.
The last case is handled mostly in the GUI front-end.
The Key window is the window that has keyboard focus and has keyboard events sent to it. When an application is launched, in many cases, only the application icon and main menu may be displayed. In the OpenStep interface, neither of these is really supposed to be a key window, and in fact, many window managers control the application icon so this cannot be made key anyway. In X-Windows, however, there is no other way for an application to receive keyboard events unless a visible window has been made key. This leaves the main menu.
When an application receives focus, or if all the windows in an application are closed (see [NSWindow-_lossOfKeyOrMainWindow]), then the main menu should get keyboard focus. This is handled in the gui frontend, so there should be nothing special done in the backend to support this.
WindowMaker controls the application icon so it does not receive keyboard events
A window may request to get keyboard focus in serveral instances. If the window asks or is asked to become key, through the [NSWindow-becomeKeyWindow] method, it will send a setinputfocus: message to the server.
If the window is ordered front and the window is the key window, it will send a setinputfocus: message.
If during _lossOfKeyOrMainWindow, only the main menu is able to become key, it will sent a setinputfoucs: message.
The GUI front-end receives two types of focus events from the back-end (through an NSEvent object). Both of these are subsets of the NSAppKitDefined event: GSAppKitWindowFocusIn and GSAppKitWindowFocusOut. Each contains a pointer to the window that should be focused. A focus in event can be received for several reasons:
The front-end does nothing for FocusOut messages.
This section describes messages that X-Windows servers and WM generally send to the application.
A message from the WM telling a window it should take keyboard focus. The back-end should only send a FocusIn event to the front end if the window asked to be key (and isn't already) or through a user action, such as a click on the title bar. The back-end may also send an event if the window has just been mapped, although this is not typically necessary, unless it's due to a screen change.
A message from the server telling the application that keyboard focus has been set for a window. The back-end should not send an event to the front-end in this case. However, the back-end should use this information to determine when to send a message in other cases (e.g. from a Take Focus message).
A message from the server telling the application that focus has left a window. If the focus has gone to a window that is not part of the application, the back-end should tell the NSApp to deactivate. Otherwise it should do nothing.