mirror of
https://github.com/gnustep/libs-back.git
synced 2025-02-23 11:51:27 +00:00
Updated
git-svn-id: svn+ssh://svn.gna.org/svn/gnustep/libs/back/trunk@15705 72102866-910b-0410-8b05-ffd578937521
This commit is contained in:
Adam Fedor
parent
c0cffa34f0
commit
ca45fd4817
2 changed files with 180 additions and 110 deletions
|
|
@ -14,39 +14,42 @@
|
|||
<chapter>
|
||||
<heading>Window Focus</heading>
|
||||
<p>
|
||||
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.
|
||||
This document describes how various events and user actions
|
||||
affect window focus of GNUstep applications. This document for
|
||||
the most part describes focus changes that occur outside of
|
||||
application control, since application window focus changes
|
||||
are well described in the class documentation.
|
||||
</p>
|
||||
|
||||
<section>
|
||||
<heading>Application Focus</heading>
|
||||
<p>
|
||||
The application can get focus in several ways.
|
||||
The application can get focus in several ways:
|
||||
</p>
|
||||
<list>
|
||||
<item>Launch from the command line or another app</item>
|
||||
<item>Another app looses focus (e.g. by terminating)</item>
|
||||
<item>Users switches screens to the one the app is displayed on</item>
|
||||
<item>The user switches screens to the one the app is
|
||||
displayed on</item>
|
||||
<item>Double-click on the application icon</item>
|
||||
</list>
|
||||
<p>
|
||||
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.
|
||||
The first case does not directly affect window focus (because
|
||||
there are no windows at startup). However, as the application
|
||||
begins to create and order front windows (including the main
|
||||
menu) there will likely be a cascade of focus events generated
|
||||
by the window manager for each window ordered in.
|
||||
</p>
|
||||
<p>
|
||||
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.
|
||||
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 request and try to give focus to
|
||||
another window, typically the application's idea of the current
|
||||
key window.
|
||||
</p>
|
||||
<p>
|
||||
The last case is handled mostly in the GUI front-end.
|
||||
The last case is handled in the GUI front-end.
|
||||
</p>
|
||||
</section>
|
||||
|
||||
|
|
@ -54,28 +57,38 @@
|
|||
<heading>KeyboardFocus</heading>
|
||||
<p>
|
||||
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.
|
||||
keyboard events sent to it. When an application receives focus,
|
||||
the window manager will typically ask one window to take
|
||||
keyboard focus (see above, Application Focus).
|
||||
</p>
|
||||
<p>
|
||||
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.
|
||||
</p>
|
||||
<p>
|
||||
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.
|
||||
application are closed (see the private method
|
||||
[NSWindow-_lossOfKeyOrMainWindow]), then the main menu will request
|
||||
keyboard focus (see below).
|
||||
</p>
|
||||
<p>
|
||||
The GUI font-end may function differently to accomadate
|
||||
different window manager behavior. Below is a list of the
|
||||
changes the front-end makes for different managers and windowing
|
||||
systems:
|
||||
</p>
|
||||
<deflist>
|
||||
<term>WindowMaker</term>
|
||||
<desc>
|
||||
<p>
|
||||
WindowMaker controls the application icon so it does not
|
||||
receive keyboard events
|
||||
WindowMaker controls the application icon so it cannot
|
||||
receive keyboard events. The main menu is made key if there is
|
||||
no other window capable of becoming key.
|
||||
</p>
|
||||
</desc>
|
||||
</deflist>
|
||||
|
|
@ -85,18 +98,19 @@
|
|||
<heading>Requesting Keyboard Focus</heading>
|
||||
<p>
|
||||
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.
|
||||
</p>
|
||||
<p>
|
||||
If the window is ordered front and the window is the key window,
|
||||
it will send a setinputfocus: message.
|
||||
</p>
|
||||
<p>
|
||||
If during _lossOfKeyOrMainWindow, only the main menu is able to
|
||||
become key, it will sent a setinputfoucs: message.
|
||||
instances. The window requests keyboard focus through the server
|
||||
method -setinputfocus::
|
||||
</p>
|
||||
<list>
|
||||
<item>If the window asks or is asked to become
|
||||
key, through the [NSWindow-becomeKeyWindow] method</item>
|
||||
<item>If the window is ordered front and the window is the key
|
||||
window.
|
||||
</item>
|
||||
<item>If during _lossOfKeyOrMainWindow, only the main menu is able to
|
||||
become key (for window systems where this is required).
|
||||
</item>
|
||||
</list>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
|
|
@ -105,20 +119,19 @@
|
|||
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
|
||||
GSAppKitWindowFocusOut. A FocusIn event can be received for
|
||||
several reasons:
|
||||
</p>
|
||||
<list>
|
||||
<item>The window manager deminiaturized the window. The WM
|
||||
should really tell the application to do this itself, but many
|
||||
WM don't. In this case the window just posts a notification
|
||||
WMs don't. In this case the window just posts a notification
|
||||
that it happened. </item>
|
||||
<item>The application is in the process of hidding. As each
|
||||
window is ordered out, the WM may send a focus message
|
||||
(spuriously) to the next window in line. In this case the
|
||||
message is just ignored. </item>
|
||||
<item>This is a real focus in message. The window checks if it
|
||||
<item>If the previous cases do not apply, the window checks if it
|
||||
can become key or main and activates the application if it is
|
||||
not active. </item>
|
||||
<item>If this window is the main menu, it looks for another
|
||||
|
|
@ -126,6 +139,14 @@
|
|||
_lossOfKeyOrMainWindow mechanism</item>
|
||||
</list>
|
||||
<p>
|
||||
The back-end should keep track of the last window that requested
|
||||
to become key. This can be important in determining whether the
|
||||
back-end should send a FocusIn event to a window when it
|
||||
receives a signal from the window manager or windowing system.
|
||||
Sending a FocusIn event to a window that already requested it,
|
||||
msy cause focus confusion in the GUI.
|
||||
</p>
|
||||
<p>
|
||||
The front-end does nothing for FocusOut messages.
|
||||
</p>
|
||||
</section>
|
||||
|
|
@ -133,20 +154,29 @@
|
|||
<section>
|
||||
<heading>X-Windows messages</heading>
|
||||
<p>
|
||||
This section describes messages that X-Windows servers and WM
|
||||
generally send to the application.
|
||||
This section describes messages that X-Windows servers and the WM
|
||||
generally send to the application. Other window servers may send
|
||||
similar messages.
|
||||
</p>
|
||||
<deflist>
|
||||
<term>Take Focus</term>
|
||||
<desc>
|
||||
<p>
|
||||
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 WM telling a window it should take keyboard
|
||||
focus. If the app is not active, the back-end should send a
|
||||
FocusIn event. Otherwise, the back-end should only send a
|
||||
FocusIn event to the front end if the message is due to a user
|
||||
action, such as a click on the title bar (i.e. the target
|
||||
window is not the current key window or the last window that
|
||||
requested key status). 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.
|
||||
</p>
|
||||
<p>
|
||||
In other cases, the back-end should do what is necessary to
|
||||
make sure that the last window to request key status receives
|
||||
it instead of the one the WM thinks should receive it.
|
||||
</p>
|
||||
</desc>
|
||||
<term>Focus In</term>
|
||||
|
|
|
|||
|
|
@ -19,17 +19,17 @@
|
|||
<h1><a name="001000000000">Window Focus</a></h1>
|
||||
<p>
|
||||
|
||||
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.
|
||||
This document describes how various events and user actions
|
||||
affect window focus of GNUstep applications. This document for
|
||||
the most part describes focus changes that occur outside of
|
||||
application control, since application window focus changes
|
||||
are well described in the class documentation.
|
||||
</p>
|
||||
|
||||
<h2><a name="001001000000">Application Focus</a></h2>
|
||||
<p>
|
||||
|
||||
The application can get focus in several ways.
|
||||
The application can get focus in several ways:
|
||||
</p>
|
||||
<ul>
|
||||
<li>
|
||||
|
|
@ -39,7 +39,8 @@
|
|||
Another app looses focus (e.g. by terminating)
|
||||
</li>
|
||||
<li>
|
||||
Users switches screens to the one the app is displayed on
|
||||
The user switches screens to the one the app is
|
||||
displayed on
|
||||
</li>
|
||||
<li>
|
||||
Double-click on the application icon
|
||||
|
|
@ -47,44 +48,57 @@
|
|||
</ul>
|
||||
<p>
|
||||
|
||||
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.
|
||||
The first case does not directly affect window focus (because
|
||||
there are no windows at startup). However, as the application
|
||||
begins to create and order front windows (including the main
|
||||
menu) there will likely be a cascade of focus events generated
|
||||
by the window manager for each window ordered in.
|
||||
</p>
|
||||
<p>
|
||||
|
||||
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.
|
||||
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 request and try to give focus to
|
||||
another window, typically the application's idea of the current
|
||||
key window.
|
||||
</p>
|
||||
<p>
|
||||
|
||||
The last case is handled mostly in the GUI front-end.
|
||||
The last case is handled in the GUI front-end.
|
||||
</p>
|
||||
|
||||
<h2><a name="001002000000">KeyboardFocus</a></h2>
|
||||
<p>
|
||||
|
||||
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.
|
||||
keyboard events sent to it. When an application receives focus,
|
||||
the window manager will typically ask one window to take
|
||||
keyboard focus (see above, Application Focus).
|
||||
</p>
|
||||
<p>
|
||||
|
||||
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.
|
||||
</p>
|
||||
<p>
|
||||
|
||||
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.
|
||||
application are closed (see the private method
|
||||
[NSWindow-_lossOfKeyOrMainWindow]), then the main menu will request
|
||||
keyboard focus (see below).
|
||||
</p>
|
||||
<p>
|
||||
|
||||
The GUI font-end may function differently to accomadate
|
||||
different window manager behavior. Below is a list of the
|
||||
changes the front-end makes for different managers and windowing
|
||||
systems:
|
||||
</p>
|
||||
<dl>
|
||||
<dt>WindowMaker</dt>
|
||||
|
|
@ -93,8 +107,9 @@
|
|||
|
||||
<p>
|
||||
|
||||
WindowMaker controls the application icon so it does not
|
||||
receive keyboard events
|
||||
WindowMaker controls the application icon so it cannot
|
||||
receive keyboard events. The main menu is made key if there is
|
||||
no other window capable of becoming key.
|
||||
</p>
|
||||
|
||||
|
||||
|
|
@ -105,20 +120,25 @@
|
|||
<p>
|
||||
|
||||
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.
|
||||
</p>
|
||||
<p>
|
||||
|
||||
If the window is ordered front and the window is the key window,
|
||||
it will send a setinputfocus: message.
|
||||
</p>
|
||||
<p>
|
||||
|
||||
If during _lossOfKeyOrMainWindow, only the main menu is able to
|
||||
become key, it will sent a setinputfoucs: message.
|
||||
instances. The window requests keyboard focus through the server
|
||||
method -setinputfocus::
|
||||
</p>
|
||||
<ul>
|
||||
<li>
|
||||
If the window asks or is asked to become
|
||||
key, through the [NSWindow-becomeKeyWindow] method
|
||||
</li>
|
||||
<li>
|
||||
If the window is ordered front and the window is the key
|
||||
window.
|
||||
|
||||
</li>
|
||||
<li>
|
||||
If during _lossOfKeyOrMainWindow, only the main menu is able to
|
||||
become key (for window systems where this is required).
|
||||
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
<h2><a name="001004000000">Window Focus In/Out</a></h2>
|
||||
<p>
|
||||
|
|
@ -126,15 +146,14 @@
|
|||
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
|
||||
GSAppKitWindowFocusOut. A FocusIn event can be received for
|
||||
several reasons:
|
||||
</p>
|
||||
<ul>
|
||||
<li>
|
||||
The window manager deminiaturized the window. The WM
|
||||
should really tell the application to do this itself, but many
|
||||
WM don't. In this case the window just posts a notification
|
||||
WMs don't. In this case the window just posts a notification
|
||||
that it happened.
|
||||
</li>
|
||||
<li>
|
||||
|
|
@ -144,7 +163,7 @@
|
|||
message is just ignored.
|
||||
</li>
|
||||
<li>
|
||||
This is a real focus in message. The window checks if it
|
||||
If the previous cases do not apply, the window checks if it
|
||||
can become key or main and activates the application if it is
|
||||
not active.
|
||||
</li>
|
||||
|
|
@ -156,14 +175,24 @@
|
|||
</ul>
|
||||
<p>
|
||||
|
||||
The back-end should keep track of the last window that requested
|
||||
to become key. This can be important in determining whether the
|
||||
back-end should send a FocusIn event to a window when it
|
||||
receives a signal from the window manager or windowing system.
|
||||
Sending a FocusIn event to a window that already requested it,
|
||||
msy cause focus confusion in the GUI.
|
||||
</p>
|
||||
<p>
|
||||
|
||||
The front-end does nothing for FocusOut messages.
|
||||
</p>
|
||||
|
||||
<h2><a name="001005000000">X-Windows messages</a></h2>
|
||||
<p>
|
||||
|
||||
This section describes messages that X-Windows servers and WM
|
||||
generally send to the application.
|
||||
This section describes messages that X-Windows servers and the WM
|
||||
generally send to the application. Other window servers may send
|
||||
similar messages.
|
||||
</p>
|
||||
<dl>
|
||||
<dt>Take Focus</dt>
|
||||
|
|
@ -172,13 +201,24 @@
|
|||
|
||||
<p>
|
||||
|
||||
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 WM telling a window it should take keyboard
|
||||
focus. If the app is not active, the back-end should send a
|
||||
FocusIn event. Otherwise, the back-end should only send a
|
||||
FocusIn event to the front end if the message is due to a user
|
||||
action, such as a click on the title bar (i.e. the target
|
||||
window is not the current key window or the last window that
|
||||
requested key status). 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.
|
||||
</p>
|
||||
|
||||
|
||||
<p>
|
||||
|
||||
In other cases, the back-end should do what is necessary to
|
||||
make sure that the last window to request key status receives
|
||||
it instead of the one the WM thinks should receive it.
|
||||
</p>
|
||||
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue