 		       Compliance of Tekwm with the
	      Inter-Client Communication Conventions Manual
			      Glenn Widener
			       XD88 release
			     November 22, 1989

This application note documents the areas of compliance of the Tekwm
window manager with Version 1 of the ICCCM.  For each sub-section of ICCCM
section 4 Client To Window Manager Communication and section 5 Client To
Session Manager Communication, it specifies the Tekwm response to
ICCCM-specified client operations, and notes the ICCCM features that are
not fully supported by Tekwm.  It also documents any client conventions
supported by Tekwm that are not documented in this version of the ICCCM.
If an ICCCM section is not specifically mentioned here, one may assume
that Tekwm complies with the specification.

			    General Operation

Tekwm incorporates some session management features as well as the usual
window management functions.  Clients can ask for WM_DELETE_WINDOW,
WM_PREPARE_TO_DIE, and WM_CLOSEDOWN messages.

		   Sec. 2.7.1, 4.1.2 Client Properties

In general, Tekwm reads client properties and attributes when the window
is mapped.  Some properties will be reread if the client changes them
after mapping, these are noted below.  If attributes are changed, the
results in Tekwm are unspecified, except for colormap, which is obeyed by
Tekwm.  Later versions will probably ignore attribute changes except for
colormap.

If a property is missing, Tekwm assumes the defaults described below for the
individual unspecified fields.

Tekwm only accepts TEXT properties of type STRING (i.e.  Latin-1).  (Note
that the current Xlib routines only support TEXT properties of type
STRING) Tabs and newlines encountered in strings that are to be displayed
(e.g.  WM_NAME) are not specially treated, and will result in printing of
whatever glyph exists in the selected font (typically none).  Note that
this is actually true for all characters in the property - the encoding
displayed is totally determined by the selected font.

Tekwm currently modifies two client-supplied property fields:
IconPositionHint (WMHints.icon_x, WMHints.icon_y) are set to the current
icon position, and the USPosition and USSize flags in WM_NORMAL_HINTS are
set once the window is positioned.

			   Sec. 4.1.2.1 WM_NAME

Tekwm displays WM_NAME in the window title bar.  Tekwm adds a space on
both ends of the string, this is only noticeable if title.text.background
color differs from title.background.  If WM_NAME does not exist, Tekwm
labels the window " Untitled Window ".

If the client changes or deletes WM_NAME after the window is mapped, Tekwm
will update the window title.

			Sec. 4.1.2.2 WM_ICON_NAME

Tekwm displays WM_ICON_NAME in the icon, if IconWindowHint and
IconPixmapHint are not specified.  If IconWindowHint or IconPixmapHint is
specified, WM_ICON_NAME is displayed in a "name icon window" under the
client icon window or pixmap.

WM_NAME is used if WM_ICON_NAME does not exist.  If neither exists, the
icon is named "Unnamed Icon".  Icon names must not be greater than 256
characters long, otherwise an error is printed and the name is truncated
to 256.  The name is not padded with any spaces at the ends.

If the client changes or deletes WM_ICON_NAME after the window is mapped,
Tekwm will update the icon.

		       Sec. 4.1.2.3 WM_NORMAL_HINTS

Per the new ICCCM, the obsolete WM_NORMAL_HINTS.x, y, width, height
fields are ignored.  If USPosition is set, the initial window size and
position are taken from the window position at map time, with size limited
by min_width/height if PMinSize is set and by max_width/height if PMaxSize
is set.  No further interaction with the user is done.

Otherwise, the default initial window size is taken from the window
geometry at map time if PSize or USSize is set, else from min_width/height
if PMinSize is set, else from max_width/height if PMaxSize is set, else
the window size at map time is used regardless of PSize or USSize.  The
new base_width and base_height fields are obeyed, with min_width and
min_height as a backup if base size is not given.  The PPosition flag is
always ignored, and the initial window position is always obtained from
the user.

If the left button is used, the default initial window size applies.
If the center button is used, the default initial window size is ignored
and the size taken from the user.

The remaining WM_NORMAL_HINTS fields are all obeyed.  If PMaxSize is not
set, the screen size is used.  PAspect is obeyed by increasing the smaller
dimension unless it would exceed the max size, otherwise by decreasing the
larger dimension unless it would fall below min size.  

			  Sec. 4.1.2.4 WM_HINTS

InputHint is ignored.  See Sec.  4.1.7. 

StateHint is supported.  Unless the -h option is given to Tekwm, StateHint
is ignored on any windows that are already mapped at Tekwm startup.  The
default is normal, de-iconified.

IconWindowHint, IconPixmapHint, and IconMaskHint (WMHints.icon_window,
WMHints.icon_pixmap, and WMHints.icon_mask) are supported.  If the client
pixmap is not specified, the mask is ignored.  If IconWindowHint and
IconPixmapHint are both specified, the window is used.  If none is
specified, WM_ICON_NAME is displayed in a small window.  If IconWindowHint
or IconPixmapHint is specified, WM_ICON_NAME is displayed in a "name icon
window" under the icon itself.  The client's icon window border width and
color are set according to the tekwm icon border resources.

IconPositionHint (WMHints.icon_x, WMHints.icon_y) is obeyed, either with
the -iconic option, or when f.iconify is executed.  The position is
interpreted as the upper left corner of the icon (unlike some window
managers which treat it as the center of the icon.)  Note that there is no
way for the client to specify an "icon gravity" hint, such as with the new
WM_NORMAL_HINTS.win_gravity, so an icon geometry of "-0-0" will place the
upper left corner of the icon at the lower right pixel on the screen, if
the client properly converts this to screen size - 1.  The default icon
position is 0,0.

WindowGroupHint is not supported at this time.

			  Sec. 4.1.2.5 WM_CLASS

Tekwm uses the WM_CLASS property to read client-specific resources, as
described in the Tekwm manual.  Note that if the client fails to set 
WM_CLASS, the WM_NAME property will be used instead, after compressing
out any whitespace in the name.

		      Sec. 4.1.2.6 WM_TRANSIENT_FOR

See sec. 4.1.10.

			Sec. 4.1.2.7 WM_PROTOCOLS

WM_TAKE_FOCUS is not supported.  See Sec.  4.1.7.  WM_PREPARE_TO_DIE,
WM_CLOSEDOWN, and WM_DELETE_WINDOW are fully supported.  See Sections
5.2.1-2.

		     Sec. 4.1.2.8 WM_COLORMAP_WINDOWS

WM_COLORMAP_WINDOWS is not supported at this time.

			  Sec. 4.1.3.1 WM_STATE

WM_STATE is fully supported.  On restart, Tekwm restores the iconic
state of the windows, and positions the icons at their previous location,
based on resetting the IconPositionHint.  (This will change to obtaining
the icon position from a private property on the client window,
WM_ICON_POSITION.)

			Sec. 4.1.3.2 WM_ICON_SIZE

The WM_ICON_SIZE property is set on the root window to a
single XIconSize that permits any size client pixmap or window, as
follows:

     min_width = min_height = 0;
     max_width = ScreenWidth;
     max_height = ScreenHeight;
     width_inc = height_inc = 1;


		     Sec. 4.1.4 Changing Window State

Tekwm fully supports the conventions for window state change in this
section.

		    Sec. 4.1.5 Configuring the Window

Tekwm fully supports the ICCCM ConfigureRequest/ConfigureNotify protocol.
Any legitimate Configure Request will be performed.  (Note that sibling
must be None or there will be a protocol error.)  Restacking is performed
with respect to the overall window, including decorations, so for example
a stack_mode of TopIf will raise the window if any part of the outside
border is occluded.

If the Wall resource is on, Tekwm will limit the client_requested
configuration so that the window and all its decorations remains fully
visible.

As a reparenting window manager, Tekwm correctly sends the client Synthetic
Notify requests where required.  The Synthetic Notifys give an adjusted
x, y window position, that is, a position which if added to the
client-requested border width gives the actual position of the upper left
pixel inside the window.  Note that this is not in general the actual
root-relative client window position.  

The border width in the Synthetic Notify is the client-requested width,
per the ICCCM.  The ICCCM does not specify the "above" field; Tekwm sets
it to None.

The ICCCM recommends that reparenting window managers set client border
widths to zero.  This will cause borderless windows to remain when a
reparenting window manager crashes.  Initially, Tekwm will not comply with
this recommendation, as the main reason for the recommendation is to
support multiple-colormap hardware.  Instead, it sets the client window's
border width and pixmap according to Tekwm's border resources.

In the future, Tekwm may set client window borders to zero.

		  Sec. 4.1.6 Changing Window Attributes

The only client window attributes modified by Tekwm are Border pixmap and
Border pixel - they are reset to the value specified by the borderColor
resource.  Note that this is contrary to the ICCCM rules.  This may change
in the future.

			  Sec. 4.1.7 Input Focus

InputHint is ignored, and WM_TAKE_FOCUS is not supported.  If the user has
directed input to the client, either by setting input focus or by moving
the pointer, all keyboard input will be passed to the client, regardless
of the input_hint, or WM_TAKE_FOCUS, and the window will be highlighted to
reflect this.  Input focus is changed only in response to user actions, so
clients following the Locally Active Input model should operate, while
Globally Active clients may encounter some problems retaining focus when
the user moves the pointer.

			   Sec. 4.1.8 Colormaps

Client window and client icon colormaps are installed when focus is in the
window.  All window decorations have their colors allocated in the client
colormap if possible, else in the default map, so that where possible the
decorations are the correct color when focus is in the window.  The client
may change the colormap for the window at any time; colormaps set at map
time and after map time are installed.

WM_COLORMAP_WINDOWS is not supported at this time.

See also section 4.1.10.

			     Sec. 4.1.9 Icons

Icons are fully supported, see Sec.  4.1.2.4 WM_HINTS.  Input events are
passed to a client's icon window if the focus is in the icon window.

		       Sec. 4.1.10 - Popup Windows
		       (Override_redirect Windows)

See also sections 4.1.8 and 4.2.2.

The ICCCM specifies that override_redirect windows get minimal support
from the window manager.  In particular, their colormaps are to be ignored
by the WM, and there is no assumption that wm ops work on them.  If their
colormap differs from that of their associated top-level window, they must
appear in the top-level window's WM_COLORMAP_WINDOWS property.  This has
several implications on how override_redirect windows may be used:

1.  clients must have a mapped top-level window to map an
override_redirect window.

2.  The client's override_redirect window must only be mapped when focus
is in its top-level window.  The client must either use the Globally
Active focus model, or else hope that the window manager is using a
real-estate focus model so that it is assured that when it receives an
event that causes mapping of the override_redirect window the colormap it
has requested is installed.

Under these rules, a client without a mapped top-level window that pops up
a menu in response to an event on the root window or another client's
window, or which asyncronously puts up a notifier when it has no top-level
window mapped cannot use override_redirect; instead, it must set a
WM_TRANSIENT_FOR property with window None on the window (and hope the
window manager pays attention, since the ICCCM does not currently specify
a response to this action).

Tekwm, however, does not follow the ICCCM in this regard.
Override_redirect window colormaps are installed when and while the window
is mapped, under the normal keyboard focus polices for a top-level window,
and all Tekwm window operations function on the override_redirect windows,
including iconification, f.decorate, etc.  The
WM_NORMAL_HINTS.initial_state field is obeyed (default:  normal,
de-iconified).  Normal processing of client-specific resources is done
based on the WM_CLASS property, causing reparenting if a borderContext or
title is requested (the default for override_redirect windows is not to
reparent or decorate).  If the window is reparented,
WM_NORMAL_HINTS.win_gravity is obeyed (default, NorthWest).

Unless client-specific resources override, Tekwm does follow the ICCCM
rules of not decorating or otherwise interfering with override_redirect
windows when they are mapped, except that it sets the border color per the
Tekwm*borderColor resource.  In particular, it does not attempt to
(re-)position the window at map time.

		       Sec. 4.1.10 - Popup Windows
			(WM_TRANSIENT_FOR Windows)

WM_TRANSIENT_FOR windows are not decorated or reparented by Tekwm, except
for setting the border color per the Tekwm*borderColor resource.  They are
mapped immediately, without any user interaction, with the geometry they
have at map time.

Currently, Tekwm does not couple a WM_TRANSIENT_FOR window with the window
it is "transient for", e.g.  they iconify separately.  This may change in
the future.

Tekwm interprets a window with a WM_TRANSIENT_FOR property with a window
of None the same as a true WM_TRANSIENT_FOR window, except that the window
will always independently (de-)iconify like a normal independent top-level
window, even if the full WM_TRANSIENT_FOR semantics are implemented.

		       Sec. 4.1.11 - Window Groups

Tekwm at the present time implements no special semantics for window
groups.  WindowGroupHint is not supported at this time.

			 Sec. 4.2.1 - Reparenting

Tekwm is a reparenting window manager, therefore all the restrictions in
this section apply.  Tekwm properly places all reparented window in its
save set.

		  Sec. 4.2.2 - Redirection of Operations

As discussed under Sec. 4.1.10, Tekwm is more lenient in its handling of
override_redirect than the ICCCM specifies.  Therefore, there is no
restriction on mapping of override_redirect windows without a non-Withdraw
top-level window.

			 Sec. 4.2.7 - Input Focus

InputHint is ignored, and WM_TAKE_FOCUS is not supported.  See Sec. 4.1.7.

		    Sec. 4.2.9 - Redirecting Requests

Tekwm makes no effort to enforce the convention described in this section.
If the client selects ResizeRedirect, and fails to properly reconfigure
the window, the client window will not properly match its parent frame.

		   Sec. 5 Session Manager Conventions

While Tekwm is not a session manager, it does use the Session Management
conventions to perform certain rudimentary session management functions,
and to implement safe window deletion and termination of clients.

Clients that have multiple independent top-level windows must support the
WM_DELETE_WINDOW protocol to operate properly with tekwm.

		      Sec. 5.1.1.2 WM_CLIENT_MACHINE

The contents of WM_COMMAND are ignored by Tekwm; it is used only for
notification that the client is ready to be killed.

		      Sec. 5.1.1.2 WM_CLIENT_MACHINE

Tekwm currently ignores this property.  Clients are restarted from a fixed
script, and there is no support for saving the current state of a session.

			  Sec. 5.1.1.3 WM_STATE

Tekwm fully supports the WM_STATE property.  The icon field is always
Tekwm's icon window, whether it is the client's icon window, or the icon
window created by Tekwm.

		      Sec. 5.2.1 Client Termination

Tekwm fully supports the WM_PREPARE_TO_DIE and WM_CLOSEDOWN protocol, from
the f.delete, f.destroy, f.terminate, f.restartsession, and f.endsession
functions.  These protocols are a proposed addition to the ICCCM to
support safe client/session termination, and were necessitated by the
restriction of WM_SAVE_YOURSELF to use in checkpointing situations.  If
the client has not asked for WM_DELETE_WINDOW, WM_PREPARE_TO_DIE, or
WM_CLOSEDOWN, these functions immediately close the client connection.  If
the client asks for WM_PREPARE_TO_DIE, it should respond similarly to
WM_SAVE_YOURSELF, but is allowed to interact with the user to dispose of
user data.  If the client asks for WM_CLOSEDOWN, it should respond by
disconnecting from the server and doing any necessary cleanup.

F.terminate ignores WM_DELETE_WINDOW, and proceeds to the
WM_PREPARE_TO_DIE and WM_CLOSEDOWN protocols.  F.kill ignores all
WM_PROTOCOLS, and immediately closes the client connection.

Once WM_COMMAND is updated, the client connection will be immediately
closed or the WM_CLOSEDOWN message sent if requested.

Tekwm uses the WM_PREPARE_TO_DIE protocol to safely shutdown itself.  When
tekwm starts up, it looks for a top-level window with the string "Wm"
somewhere it its WM_CLASS.res_name.  If found, Tekwm performs a client
shutdown on the window by sending the WM_PREPARE_TO_DIE message, then
waiting for 45 seconds for the window to be deleted before doing a
KillClient on the window.  Tekwm then creates an unmapped top-level window
at the bottom of the root window stack, gives it the WM_CLASS.res_name
name "Tekwm" and .res_class "Tekwm.Wm" and the window name "Tekwm
WM_PROTOCOLS window", and requests the WM_PREPARE_TO_DIE protocol on that
window, and procedds with startup.

			Sec. 5.2.2 Window Deletion

Tekwm fully supports the WM_DELETE_WINDOW protocol, from the f.delete,
f.destroy, f.restartsession, and f.endsession functions.  If the client
has not asked for WM_DELETE_WINDOW, these functions proceed to the
WM_PREPARE_TO_DIE and WM_CLOSEDOWN protocols.

			      Sec. 6.3 Grabs

Tekwm does not fully comply with this (recently added) section of the
ICCCM.  Tekwm will establish Grabs on the client window if its tekwmrc
files define any bindings to client window context.  If a client attempts
to Grab the same Button-Modifier combination specified for Tekwm's
bindings, the client will get an Access error.

This non-compliance may be eliminated in a future release, by grabbing the
buttons on the Root window.

The Tektronix default user interface configures Tekwm to use any of the
Mouse Buttons combined with the Meta (MOD1) modifier.

To avoid the conflict, the user must reconfigure either Tekwm's or the
client's user interface.  This will remain true even if Tekwm is modified
to comply with the ICCCM.

			    Sec. 6.4 Colormaps

Tekwm does not include any support for Standard Colormaps or
WM_COLORMAP_WINDOWS at this time.
