7. Implementation notes

7.1. Desktop/workspace model

This spec assumes a desktop model that consists of one or more completely independent desktops which may or may not be larger than the screen area. When a desktop is larger than the screen it is left to the window manager if it will implement scrolling or paging.

7.2. File Manager desktop

This spec suggests implementing the file manager desktop by mapping a desktop-sized window (no shape) to all desktops, with _NET_WM_WINDOW_TYPE_DESKTOP. This makes the desktop focusable and greatly simplifies implementation of the file manager. It is also faster than managing lots of small shaped windows. The file manager draws the background on this window. There should be a root property with a window handle for use in applications that want to draw the background (xearth).

7.3. Implementing enhanced support for application transient windows

If the WM_TRANSIENT_FOR property is set to None or Root window, the window should be treated as a transient for all other windows in the same group. It has been noted that this is a slight ICCCM violation, but as this behaviour is pretty standard for many toolkits and window managers, and is extremely unlikely to break anything, it seems reasonable to document it as standard.

7.4. Urgency

Dialog boxes should indicate their urgency level (information or warning) using the urgency bit in the WM_HINTS.flags property, as defined in the ICCCM.

7.5. Fixed size windows

Windows can indicate that they are non-resizable by setting minheight = maxheight and minwidth = maxwidth in the ICCCM WM_NORMAL_HINTS property. The Window Manager MAY decorate such windows differently.

7.6. Pagers and Taskbars

This specification attempts to make reasonable provisions for WM independent pagers and taskbars. Window Managers that require / desire additional functionality beyond what can be achieved using the mechanisms set out in this specification may choose to implement their own pagers, which communicates with the Window Manager using further, WM-specific hints, or some other means.

Pagers should decide whether to show a miniature version of a window using the following guidelines:

7.7. Window Movement

Window manager implementors should refer to the ICCCM for definitive specifications of how to handle MapRequest and ConfigureRequest events. However, since these aspects of the ICCCM are easily misread, this document offers the following clarifications:

[1] ICCCM Version 2.0, §4.1.2.3 and §4.1.5

[2] ICCCM Version 2.0, §4.2.3

7.8. Window-in-Window MDI

The authors of this specification acknowledge that there is no standard method to allow the Window Manager to manage windows that are part of a Window-in-Window MDI application. Application authors are advised to use some other form of MDI, or to propose a mechanism to be included in a future revision of this specification.

7.9. Killing Hung Processes

If processes fail to respond to the _NET_WM_PING protocol _NET_WM_PID may be used in combination with the ICCCM specified WM_CLIENT_MACHINE to attempt to kill a process.

WM_CLIENT_MACHINE must be set to the fully-qualified domain name of the client's host. This would normally be retrieved using gethostname(2). When gethostname() is not available on the client's platform implementors may use the value of the nodename field of struct utsname as returned by uname(2). An example of how to retrieve a value for WM_CLIENT_MACHINE:

int net_get_hostname (char *buf, size_t maxlen)
{
#ifdef HAVE_GETHOSTNAME
	if (buf == NULL) return 0;

	gethostname (buf, maxlen);
	buf [maxlen - 1] = '\0';

	return strlen(buf);
#else
	struct utsname name;
	size_t len;

	if (buf == NULL) return 0;

	uname (&name);
	len = strlen (name.nodename);

	if (len >= maxlen) len = maxlen - 1;
	strncpy (buf, name.nodename, len);
	buf[len] = '\0';

	return len;
#endif
}