3.4.1.3.2 WM_ICON SIZE Property

A window manager that wishes to place constraints on the sizes of icon pixmaps and/or windows should place a property called WM_ICON_SIZE on the root. The contents of this property are listed in the following table.

3.4.1.4 Changing Window State

From the client's point of view, the window manager will regard each of the client's top-level nonoverride-redirect windows as being in one of three states, whose semantics are as follows:

• NormalState - The client's top-level window is visible.
• IconicState - The client's top-level window is iconic (whatever that means for this window manager). The client can assume that its icon_window (if any) will be visible and, failing that, its icon_pixmap (if any) or its WM_ICON_NAME will be visible.
• WithdrawnState - Neither the client's top-level window nor its icon are visible.

In fact, the window manager may implement states with semantics other than those described above. For example, a window manger might implement a concept of "inactive" state in which an infrequently used client's window would be represented as a string in a menu. But this state is invisible to the client, which would see itself merely as being in IconicState.

Newly created top-level windows are in the Withdrawn state. Once the window has been provided with suitable properties, the client is free to change its state as follows:

• WithdrawnNormal - The client should map the window with WM_HINTS.initial_state being NormalState.
• WithdrawnIconic - The client should map the window with WM_HINTS.initial_state being IconicState.
• NormalIconic - The client should send a client message event as described later in this section.
• NormalWithdrawn - The client should unmap the window and follow it with a synthetic UnmapNotify event as described later in this section.
• IconicNormal - The client should map the window. The contents of WM_HINTS.initial_state are irrelevant in this case.
• IconicWithdrawn - The client should unmap the window and follow it with a synthetic UnmapNotify event as described later in this section.

Only the client can effect a transition into or out of the Withdrawn state. Once a client's window has left the Withdrawn state, the window will be mapped if it is in the Normal state and the window will be unmapped if it is in the Iconic state. Reparenting window managers must unmap the client's window when it is in the Iconic state, even if an ancestor window being unmapped renders the client's window unviewable. Conversely, if a reparenting window manager renders the client's window unviewable by unmapping an ancestor, the client's window is by definition in the Iconic state and must also be unmapped.

Advice to Implementors

Clients can select for StructureNotify on their top-level windows to track transitions between Normal and Iconic states. Receipt of a MapNotify event will indicate a transition to the Normal state, and receipt of an UnmapNotify event will indicate a transition to the Iconic state.

When changing the state of the window to Withdrawn, the client must (in addition to unmapping the window) send a synthetic UnmapNotify event by using a SendEvent request with the following arguments:

Rationale

The reason for requiring the client to send synthetic UnmapNofity event is to ensure that the window manager gets some notification of the client's desire to change state, even thought he window may already be unmapped when the desire is expressed .

Advice to Implementors

For compatibility with obsolete clients, window mangers should trigger the transition to the Withdrawn state on the real UnmapNotify rather than waiting for the synthetic one. They should also trigger the transition if they receive a synthetic UnmapNotify on a window for which they have not yet received a real UnmapNotify.

When a client withdraws a window, the window manager will then update or remove the WM_STATE property as described in Section 3.4.1.3.1. Clients that want to re-use a client window (e.g. by mapping it again or reparenting it elsewhere) after withdrawing it must wait for the withdrawal to be complete before proceeding. The preferred method for doing this is for client to wait for the window manager to update or remove the WM_STATE property.

(Note: Earlier versions of these conventions prohibited clients from reading the WM_STATE property. Clients operating under to earlier conventions used the technique of tracking ReparentNotify events to wait for the top-level window to be reparented back to the root window. This R still a valid technique: however. h works only for reparenting window managers. and the WM_STATE technique is to be preferred. )

If the transition is from the Normal to the Iconic state, the client should send a ClientMessage event to the root with:

• Window == the window to be iconified
• Type = the atom WM_CHANGE_STATE
• Format== 32
• Datal0] == IconicState

Rationale

The format of this ClientMessage event dopes not match the format of ClientMessage in Section 3.4.2.8. This is because they are sent by the window manager to clients, and this message is sent by clients to the window manager.

Over values of data[0] are reserved for future extensions to these conventions. The parameters of the SendEvent request should be those described for the synthetic UnmapNotify event.

Advice to Implementors

Clients can also select for VisibilityChange events on their top-level or icon windows. They will then receive a VisibilityNotify (state==FullyObscured) event when the window concerned becomes completely obscured even though mapped (and thus, perhaps a waste of time to update) and a VisibilityNotify (state!=FullyObscured) event when it becomes even partly viewable.

Advice to Implementors

When a window makes a transition from the Normal state to either the Iconic or to the Withdrawn state, clients should be aware that the window manager may make transients for this window inaccessible. Clients should not rely on transient windows being available to the user when the transient owner window is not in the Normal state. When withdrawing a window, clients are advised to withdraw transients for the window.

3.4.1.5 Configuring the Window

Clients can resize and reposition their top-level windows by using the ConfigureWindow request. The attributes of the window that Can be altered with this request are as follows:

• The [x,y] location of the window's upper left-outer corner
• The [width,height] of the inner region of the window (excluding borders)
• The border width of the window
• The window's position in the stack

The coordinate system in which the location is expressed is that of the root (irrespective of any reparenting that may have occurred). The border width to be used and win_gravity position hint to be used are those most recently requested by the client. Client configure requests are interpreted by the window manager in the same manner as the initial window geometry mapped from the Withdrawn state, as described in Section 3.4.1.2.3. Clients must be aware that there is no guarantee that the window manager will allocate them the requested size or location and must be prepared to deal with any size and location. If the window manager decides to respond to a ConfigureRequest request by:

• Not changing the size, location, border width, or stacking order of the window at all
  A client will receive a synthetic ConfigureNotify event that describes the (unchanged) state of the window. The (x,y) coordinates will be in the root coordinate system and adjusted for the border width the client requested, irrespective of any reparenting that has taken place. The border_width will be the border width the client requested. The client will not receive a real ConfigureNotify event because no change has actually taken place.



• Moving or restacking the window without resizing it or changing its border width
  A client will receive a synthetic ConfigureNotify event following the move that describes the new state of the window, whose (x,y) coordinates will be in the root coordinate system adjusted for the border width the client requested. The border_width will be the border width the client requested. The client may not receive a real ConfigureNotify event that describes this change because the window manager may have reparented the top-level window. If the client does receive a real event, the synthetic event will follow the real one.



• Resizing the window or changing its border width (regardless of whether the window was also moved or restacked)
  A client that has selected for StructureNotify events will receive a ConfigureNotify event. Note that the coordinates in this event are relative to the parent, which may not be the root if the window has been reparented. The coordinates will reflect the actual border width of the window (which the window manager may have changed). The TranslateCoordinates request can be used to convert the coordinates if required.

The general rule is that coordinates in real ConfigureNotify events are in the parent's space; in synthetic events, they are in the root space.

Advice to Implementors

Clients cannot distinguish between the case where a top-level window is resized and moved from the case where the window is resized but not moved, since a real ConflgureNotify event will be received in both cases. Clients that are concerned with keeping track of the absolute position of a top-level window should keep a piece of state indicating whether they are certain of its position. Upon receipt of a real ConfigureNotify event on the top-level window, the client should note that the position is unknown. Upon receipt of a synthetic ConfigureNotify event, the client should note the position as known, using the position in this event. If the client receives a KeyPress, KeyRelease, ButtonPress, ButtonRelease, MotionNofity, EnterNotify, or LeaveNotify event on the window (or on any descendant), the client can deduce the top-level window's position form he difference between the (event-x, event-y) and (root-x, root-y) coordinates in these events. Only when the position is unknown does the client need to use the TranslateCfoordinates request to find the position of a top-level window.

Clients should be aware that their borders may not be visible. Window managers are free to use reparenting techniques to decorate client's top-level windows with borders containing titles, controls, and other details to maintain a consistent look-and-feel. If they do, they are likely to override the client's attempts to set the border width and set it to zero. Clients, therefore, should not depend on the top-level window's border being visible or use it to display any critical information. Other window managers will allow the top-level windows border to be visible.

Convention

Clients should set the desired value of the border-width attribute on all ConfigureWindow requests to avoid a race condition.

Clients that change their position in the stack must be aware that they may have been reparented, which means that windows that used to be siblings no longer are. Using a nonsibling as the sibling parameter on a ConfigureWindow request will cause an error.

Convention

Clients that use a ConfigureWindow request to request a change in their position in the stack should do so using None in the sibling field.

Clients that must position themselves in the stack relative to some window that was originally a sibling must do the Configure Window request (in case they are running under a nonreparenting window manager), be prepared to deal with a resulting error, and then follow with a synthetic ConfigureRequest event by invoking a SendEvent request with the following arguments:

Window managers are in any case free to position windows in the stack as they see fit, and so clients should not rely on receiving the stacking order they have requested. Clients should ignore the above-sibling field of both real and synthetic ConfigureNotify events received on their top-level windows because this field may not contain useful information.

3.4.1.6 Changing Window Attributes

The attributes that may be supplied when a window is created may be changed by using the ChangeWindowAttributes request. The window attributes are listed in the following table.

Most attributes are private to the client and will never be interfered with by the window manager. For the attributes that are not private to the client:

• The window manager is free to override the window gravity; a reparenting window manager may want to set the top-level window's window gravity for its own purposes.
• Clients are free to set the save-under hint on their top-level windows, but they must be aware that the hint may be overridden by the window manager.
• Windows, in effect, have per-client event masks, and so, clients may select for whatever events are convenient irrespective of any events the window manager is selecting for. There are some events for which only one client at a time may select, but the window manager should not select for them on any of the client's windows.
• Clients can set override-redirect on top-level windows but are encouraged not to do so except as described in Sections 3.4.1.10 and 3.4.2.9.

3.4.1.7 Input Focus

There are four models of input handling:

• No Input - The client never expects keyboard input. An example would be xload or another output-only client.
• Passive Input - The client expects keyboard input but never explicitly sets the input focus. An example would be a simple client with no subwindows, which will accept input in PointerRoot mode or when the window manager sets the input focus to its top-level window (in click-to-type mode).
• Locally Active Input - The client expects keyboard input and explicitly sets the input focus, but it only does so when one of its windows already has the focus. An example would be a client with subwindows defining various data entry fields that uses Next and Prev keys to move the input focus between the fields. It does so when its top-level window has acquired the focus in PointerRoot mode or when the window manager sets the input focus to its top-level window (in click-to-type mode).
• Globally Active Input - The client expects keyboard input and explicitly sets the input focus, even when it is in windows the client does not own. An example would be a client with a scroll bar that wants to allow users to scroll the window without disturbing the input focus even if it is in some other window. It wants to acquire the input focus when the user clicks in the scrolled region but not when the user clicks in the scroll bar itself. Thus, it wants to prevent the window manager from setting the input focus to any of its windows.

The four input models and the corresponding values of the input field and the presence or absence of the WM TAKE_FOCUS atom in the WM_PROTOCOLS property are listed in the following table:

Passive and Locally Active clients set the input field of WM_HINTS to True, which indicates that they require window manager assistance in acquiring the input focus. No Input and Globally Active clients set the input field to False, which requests that the window manager not set the input focus to their top-level window.

Clients that use a SetInputFocus request must set the time field to the timestamp of the event that caused them to make the attempt. This cannot be a FocusIn event because they do not have timestamps. Clients may also acquire the focus without a corresponding EnterNotify. Note that clients must not use CurrentTime in the time field.

Clients using the Globally Active model can only use a SetInputFocus request to acquire the input focus when they do not already have it on receipt of one of the following events:

• ButtonPress
• ButtonRelease
• Passive-grabbed KeyPress
• Passive-grabbed KeyRelease

In general, clients should avoid using passive-grabbed key events for this purpose, except when they are unavoidable (as, for example, a selection tool that establishes a passive grab on the keys that cut, copy, or paste).

The method by which the user commands the window manager to set the focus to a window is up to the window manager. For example, clients cannot determine whether they will see the click that transfers the focus.

Windows with the atom WM_TAKE_FOCUS in their WM_PROTOCOLS property may receive a ClientMessage event from the window manager (as described in Section 3.4.2.8) with WM_TAKE_FOCUS in their data[0] field and a valid timestamp (i.e. not Current Time) in its data[1] field. If they want the focus, they should respond with a SetInputFocus request with its window field set to the window of their that last had the input focus or their "default input window," and the time field set to the timestamp in the message. For further information, see Section 3.4.2.7.
SetInputFocus request with its window field set to the window of theirs that last had the input focus or to their "default input window," and the time field set to the timestamp in the message. For further information, see Section 3.4.2.7.

A client could receive WM_TAKE_FOCUS when opening from an icon or when the user has clicked outside the top-level window in an area that indicates to the window manager that it should assign the focus (for example, clicking in the headline bar can be used to assign the focus).

The goal is to support window managers that want to assign the input focus to a top-level window in such a way that the top-level window either can assign it to one of its subwindows or can decline the offer of the focus. For example, a clock or a text editor with no currently open frames might not want to take focus even though the window manager generally believes that clients should take the input focus after being deiconified or raised.

Clients that set the input focus need to decide a value for the revert-to field of the SetInputFocus request. This determines the behavior of the input focus if the window the focus has been set to becomes not viewable. The value can be any of the following:

• Parent - In general, clients should use this value when assigning focus to one of their subwindows. Unmapping the subwindow will cause focus to revert to the parent, which is probably what you want.
• PointerRoot - Using this value with a click-to-type focus management policy leads to race conditions because the window becoming unviewable may coincide with the window manager deciding to move the focus elsewhere.
• None - Using this value causes problems if the window manager reparents the window, as most window managers will, and then crashes. The input focus will be None, and there will probably be no way to change it.

Note that neither PointerRoot nor None is really safe to use.

Convention

Clients that invoke a SetInputFocus request should set the revert-to argument to Parent.

A convention is also required for clients that want to give up the input focus. There is no safe value set for them to set the input focus to; therefore, they should ignore input material.

Convention

Clients should not give up the input focus of their own volition. They should ignore input that they receive instead.

3.4.1.8 Colormaps

The window manager is responsible for installing and uninstalling colormaps on behalf of clients with top-level windows that the window manager manages.

Clients provide the window manager with hints as to which colormaps to install and uninstall. Clients must not install or uninstall or colormaps themselves (except under the circumstances noted below). When a client's top-level window gets the colormap focus (as a result of whatever colormap focus policy is implemented by the window manager), the window manager will ensure that one or more of the client's colormaps are installed.

Clients whose top-level windows and subwindows all use the same colormap should set its ID in the colromap field of the top-level window's attributes. They should not set a WM_COLORMAP_WINDOWS property on the top-level window. If they want to change the colormap, they should change the top-level window's colromap attribute. The window manager will track changes to the window's colormap attribute and install colormaps as appropriate.

Clients that create windows can use the value CopyFromParent to inherit their parent's colormap. Window managers will ensure that the root window's colormap field contains a colormap that is suitable for clients to inherit. In particular, the colormap will provide distinguishable colors for BlackPixel and WhitePixel.

Top-level windows that have subwindows or override-redirect pop-up windows whose colormap requirements differ from the top-level window should have a WM_COLORMAP_WINDOWS property. This property contains a list of IDs for windows whose colormaps the window manager should attempt to have installed when, in the course of its individual colormap focus policy, it assigns the colormap focus to the top-level window (see Section 3.4.1.2.8). The list is ordered by the importance to the client of having the colormaps installed. The window manager will track changes to this property and will track changes to the colormap attribute of the windows in the property.

If the relative importance of colormaps changes, the client should update the WM_COLORMAP_WINDOWS property to reflect the new ordering. If the top-level window does not appear in the list, the window manager will assume it to be of higher priority than any window in the list.

WM_TRANSIENT_FOR windows either can have their own WM_COLORMAP_WINDOWS property or can appear in the property of the window they are transient for, as appropriate.

Rationale

An alternative design was considered for how clients should hint to the window manager about their colormap requirements. This alternative design specified a list of colormaps instead of a list of windows. The current design, a list of windows, was chosen for two reasons. First, it allows window managers to find the visuals of the colormaps, thus permitting visual-dependent colormap installation policies. Second, it allows window managers to select for VisibilityChange events on the windows concerned and to ensure that colormaps are only installed if the windows that need them are visible. The alternative design allows for neither of these policies.

Advice to Implementors

Clients should be aware of the min-installed-maps and max-installed-maps fields of the connection setup information, and the effect that the minimum value has on the "required list" defined by the Protocol in the description of the InstallColormap request. Briefly, the min-installed-maps most recently installed maps are guaranteed to be installed. This value is often one; clients needing multiple colormaps should beware.

Whenever possible, clients should use the mechanisms described above and let the window manager handle colormap installation. However, clients are permitted to perform colormap installation on their own while they have the pointer grabbed. A client performing colormap installation must notify the window manager prior to the first installation. When the client has finished its colormap installation, it must also notify the window manager. The client notifies the window manager by issuing a SendEvent request with the following arguments:

This feature was introduced in version 2.0 of this document, and there will be a significant period of time before all window managers can be expected to implement this feature. Before using this feature, clients must check the compliance level of the window manager (using the mechanism described in Section 3.4.2.3) to verify that it supports this feature. This is necessary to prevent colormap installation conflicts between clients and older window managers.

Window managers should refrain from installing colormaps while a client has requested control of colormap installation. The window manager should continue to track the set of installed colormaps so that it can reinstate its colormap focus policy when the client has finished colormap installation.

This technique has race conditions that may result in the colormaps continuing to be installed even after a client has issued is notification message. For example, the window manager may have issued some InstallColormap requests that are not executed until after the client's SendEvent and InstallColormap requests, thus uninstalling the client's colormaps. If this occurs while the client sill has the pointer grabbed and before the client has issued the "finished" message, the client may reinstall the desired colormaps.

Advice to Implementors

Clients are expected to use this mechanism for things such as popup windows and for animations that use override-redirect windows.

If a client fails to issue the "finished" message, the window manager may be left in a state where its colormap installation policy is suspended. Window manger implementors may want to implement a feature that resets colormap installation policy in response to a command from the user.

3.4.1.9 Icons

A client can hint to the window manager about the desired appearance of its icon by setting:

• A string in WM_ICON_NAME
  All clients should do this because it provides a fallback for window managers whose ideas about icons differ widely from those of the client.
• A Pixmap into the icon_pixmap field of the WM_HINTS property and possibly another into the icon_mask field
  The window manager is expected to display the pixmap masked by the mask. The pixmap should be one of the sizes found in the WM_ICON_SIZE property on the root. If this property is not found, the window manager is unlikely to display icon pixmaps. Window managers usually will clip or tile pixmaps that do not match WM_ICON_SIZE.
• A window into the icon_window field of the WM_HINTS property
  The window manager is expected to map that window whenever the client is in the Iconic state. In general, the size of the icon window should be one of those specified in WM_ICON_SIZE on the root, if it exists. Window managers are free to resize icon windows.

In the Iconic state, the window manager usually will ensure that:

• If the window's WM_HINTS.icon_window is set, the window it names is visible.
• If the window's WM_HINTS.icon_window is not set but the window's WM_HINTS.icon_pixmap is set, the pixmap it names is visible.
• Otherwise, the window's WM_ICON_NAME string is visible.

Clients should observe the following conventions about their icon windows:

Conventions

1. The icon window should be an InputOutput child of the root.

2. The icon window should be one of the sizes specified in the WM_ICON_SIZE property on the root.

3. The icon window should use the root visual and default colormap for the screen in question.

4. Clients should not map their icon windows.

5. Clients should not unmap their icon windows.

6. Clients should not configure their icon windows.

7. Clients should not set override-redirect on their icon windows or select for ResizeRedirect events on them.

8. Clients must not depend on being able to receive input events by means of their icon windows.

9. Clients must not manipulate the borders of their icon windows.

10. Clients must select for Exposure events on their icon window and repaint it when requested.

Window managers will differ as to whether they support input events to client's icon windows;
most will allow the client to receive some subset of the keys and buttons.

Window managers will ignore any WM_NAME, WM_ICON_NAME, WM_NORMAL_HINTS, WM_HINTS, WM_CLASS, WM_TRANSIENT_FOR, WM_PROTOCOLS, or WM_COLORMAP_WINDOWS properties they find on icon windows. Session managers will ignore any WM_COMMAND or WM_CLIENT_MACHINE properties they find on icon windows.

3.4.1.10 Pop-up Windows

Clients that wish to pop up a window can do one of three things:

1. They can create and map another normal top-level window, which will get decorated and managed as normal by the window manager. See the discussion of window groups that follows.
2. If the window will be visible for a relatively short time and deserves a somewhat lighter treatment, they can set the WM_TRANSIENT_FOR property. They can expect less decoration but can set all the normal window manager properties on the window. An example would be a dialog box.
3. If the window will be visible for a very short time and should not be decorated at all, the client can set override-redirect on the window. In general, this should be done only if the pointer is grabbed while the window is mapped. The window manager will never interfere with these windows, which should be used with caution. An example of an appropriate use is a pop-up menu.

   Advice to Implementors

   The user will not be able to move, resize, restack, or transfer the input focus to override-redirect windows, since the window manager is not managing them. If it is necessary for a client to receive keystrokes on an override-redirect window, either the client must grab the keyboard, or the client must have another top-level window that is not override-redirect and that has selected the Locally Active or Globally Active focus model. The client may set the focus to the override-redirect window when the other window receives a WM_TAKE_FOCUS message or one of the events listed in Section 3.4.l.7 in the description of the Globally Active focus model.

Window managers are free to decide if WM_TRANSIENT_FOR windows should be iconified when the window they are transient for is. Clients displaying WM_TRANSIENT_FOR windows that have (or request to have) the window they are transient for iconified do not need to request that the same operation be performed on the WM_TRANSIENT_FOR window; the window manager will change its state if that is the policy it wishes to enforce.

3.4.1.11 Window Groups

A set of top-level windows that should be treated from the user's point of view as related (even though they may belong to a number of clients) should be linked together using the window_group field of the WM_HINTS structure.

One of the windows (that is, the one the others point to) will be the group leader and will carry the group as opposed to the individual properties. Window managers may treat the group leader differently from other windows in the group. For example, group leaders may have the full set of decorations, and other group members may have a restricted set.

It is not necessary that the client ever map the group leader; it may be a window that exists solely as a placeholder .

It is up to the window manager to determine the policy for treating the windows in a group. At present, there is no way for a client to request a group, as opposed to an individual, operation.

3.4.2 Client Responses to Window Manager Actions

The window manager performs a number of operations on client resources, primarily on their top-level windows. Clients must not try to fight this but may elect to receive notification of the window manager's operations.

3.4.2.1 Reparenting

Clients must be aware that some window managers will reparent their top-level windows so that a window that was created as a child of the root will be displayed as a child of some window belonging to the window manager. The effects that this reparenting will have on the client are as follows:

• The parent value returned by a QueryTree request will no longer be the value supplied to the CreateWindow request that created the reparented window. There should be no need for the client to be aware of the identity of the window to which the top-level window has been reparented. In particular, a client that wishes to create further top-level windows should continue to use the root as the parent for these new windows.
• The server will interpret the (x,y) coordinates in a ConfigureWindow request in the new parent's coordinate space. In fact, they usually will not be interpreted by the server because a reparenting window manager usually will have intercepted these operations (see Section 3.4.2.2). Clients should use the root coordinate space for these requests (see Section 3.4.l.5).
• ConfigureWindow requests that name a specific sibling window may fail because the window named, which used to be a sibling, no longer is after the reparenting operation (see Section 3.4.1.5).
• The (x,y) coordinates returned by a GetGeometry request are in the parent's coordinate space and are thus not directly useful after a reparent operation.
• A background of ParentRelative will have unpredictable results.
• A cursor of None will have unpredictable results.

Clients that want to be notified when they are reparented can select for StructureNotify events on their top-level window. They will receive a ReparentNotify event if and when reparenting takes place.

When a client withdraws a top-level window, the window manager will reparent it back to the root window if the window had been reparented elsewhere.

If the window manager reparents a client's window, the reparented window will be placed in the save-set of the parent window. This means that the reparented window will not be destroyed if the window manager terminates and will be remapped if it was unmapped. Note that this applies to all client windows the window manager reparents, including transient windows and client icon windows.

3.4.2.2 Redirection of Operations

Clients must be aware that some window managers will arrange for some client requests to be intercepted and redirected. Redirected requests are not executed; they result instead in events being sent to the window manager, which may decide to do nothing, to alter the arguments, or to perform the request on behalf of the client.

The possibility that a request may be redirected means that a client cannot assume that any redirectable request is actually performed when the request is issued or is actually performed at all.

The requests that may be redirected are MapWindow, Configure Window, and Circulate-Window.

Advice to Implementors

The following is incorrect because the MapWindow request may be intercepted and the PolyLine output made to an unmapped window:

MapWindow A

PolyLine A GC <point><point>...

The client must wait for an Expose event before drawing in the window

(Note: This is true even if the client set the hacking-store attribute to Always. The backing-store attribute is a only d him and the server may stop maintaining backing store contents at any time. )

This next example incorrectly assumes that the ConfigureWindow request is actually executed with the arguments supplied:

ConfigureWindow width=N height=M

<output assuming window N by M>

The client should select for StructureNotify on its window and monitor the window's size by tracking ConfigureNotify events.
Clients must be especially careful when attempting to set the focus to a window that they have just mapped. This sequence may result in an X protocol error:

Mapwindow B

SetInputFocus B

If the MapWindow request has been intercepted, the window will still be unmapped, causing the SetInputFocus request to generate the error. The solution to this problem is for clients to select for VisibilityChange on the window and to delay the issuance of the SetInputFocus request until they have received a VisibilityNotify event indication that the window is visible.

This technique does not guarantee correct operation. The user may have iconified the window by the time the SetInputFocus request reaches the server, still causing an error. Or, the window manger may decide to map the window into Iconic state, in which case the window will not be visible. This will delay the generation for the VisibilityNotify event indefinitely. Clients must be prepared to handle these cases.

A window with the override-redirect bit set is immune from redirection, but the bit should be set on top-level windows only in cases where other windows should be prevented from processing input while the override-redirect window is mapped (see Section 3.4.1.10) and while responding to ResizeRequest events (see Section 3.4.2.9).

Clients that have no non-Withdrawn top-level windows and that map an override-redirect toplevel window are taking over total responsibility for the state of the system. It is their responsibility to:

• Prevent any preexisting window manager from interfering with their activities
• Restore the status quo exactly after they unmap the window so that any preexisting window manager does not get confused

In effect, clients of this kind are acting as temporary window managers. Doing so is strongly discouraged because these clients will be unaware of the user interface policies the window manager is trying to maintain and because their user interface behavior is likely to conflict with that of less demanding clients.

3.4.2.3 Window Move

If the window manager moves a top-level window without changing its size, the client will receive a synthetic ConfigureNotify event following the move that describes the new location in terms of the root coordinate space. Clients must not respond to being moved by attempting to move themselves to a better location.

Any real ConfigureNotify event on a top-level window implies that the window's position on the root may have changed, even though the event reports that the window's position in its parent is unchanged because the window may have been reparented. Note that the coordinates in the event will not, in this case, be directly useful.

The window manager will send these events by using a SendEvent request with the following arguments:

3.4.2.4 Window Resize

The client can elect to receive notification of being resized by selecting for StructureNotify events on its top-level windows. It will receive a ConfigureNotify event. The size information in the event will be correct, but the location will be in the parent window (which may not be the root).

The response of the client to being resized should be to accept the size it has been given and to do its best with it. Clients must not respond to being resized by attempting to resize themselves to a better size. If the size is impossible to work with, clients are free to request to change to the Iconic state.

3.4.2.5 Iconify and Deiconify

A top-level window that is not Withdrawn will be in the Normal state if it is mapped and in the Iconic state if it is unmapped. This will be true even if the window has been reparented; the window manager will unmap the window as well as its parent when switching to the Iconic state.

The client can elect to be notified of these state changes by selecting for StructureNotify events on the top-level window. It will receive a UnmapNotify event when it goes Iconic and a MapNotify event when it goes Normal.

3.4.2.6 Colormap Change

Clients that wish to be notified of their colormaps being installed or uninstalled should select for ColormapNotify events on their top-level windows and on any windows they have named in WM_COLORMAP_WINDOWS properties on their top-level windows. They will receive ColormapNotify events with the new field FALSE when the colormap for that window is installed or uninstalled.

3.4.2.7 Input Focus

Clients can request notification that they have the input focus by selecting for FocusChange events on their top-level windows; they will receive FocusIn and FocusOut events. Clients that need to set the input focus to one of their subwindows should not do so unless they have set WM_TAKE_FOCUS in their WM_PROTOCOLS property and have done one of the following:

• Set the input field of WM_HINTS to True and actually have the input focus in one of their top-level windows
• Set the input field of WM_HINTS to False and have received a suitable event as described in Section 3.4.1.7
• Have received a WM_TAKE_FOCUS message as described in Section 3.4.1.7

Clients should not warp the pointer in an attempt to transfer the focus; they should set the focus and leave the pointer alone. For further information, see Section 3.6.2.

Once a client satisfies these conditions, it may transfer the focus to another of its windows by using the SetInputFocus request, which is defined as follows:

SetInputFocus

focus: WINDOW or PointerRoot or None
revert-to: {Parent, PointerRoot, None}
time: TIMESTAMP or CurrentTime

Conventions

1. Clients that use a SetInputFocus request must set the time argument to the times tamp of the event that caused them to make the attempt. This cannot be a FocusIn event because they do not have timestamps. Clients may also acquire the focus without a corresponding EnterNotify event. Clients must not use CurrentTime for the time argument.
   
2. Clients that use a SetInputFocus request to set the focus to one of their windows must Set the revert-to field to Parent.

3.4.2.8 ClientMessage Events

There is no way for clients to prevent themselves being sent ClientMessage events.

Top-level windows with a WM_PROTOCOLS property may be sent ClientMessage events specific to the protocols named by the atoms in the property (see Section 3.4.1.2.7). For all protocols, the ClientMessage events have the following

• WM_PROTOCOLS as the type field
• Format 32
• The atom that names their protocol in the data[0] field
• A timestamp in their data[1] field

The remaining fields of the event, including the window field, are determined by the protocol.

These events will be sent by using a SendEvent request with the following arguments:

3.4.2.8.1 Window Deletion

Clients, usually those with multiple top-level windows, whose server connection must survive the deletion of some of their top-level windows, should include the atom WM_DELETE_WINDOW in the WM_PROTOCOLS property on each such window. They will receive a ClientMessage event as described above whose data[0] field is WM_DELETE_WINDOW.

Clients receiving a WM_DELETE_WINDOW message should behave as if the user selected "delete window" from a hypothetical menu. They should perform any confirmation dialog with the user and, if they decide to complete the deletion, should do the following:

• Either change the window's state to Withdrawn (as described in Section 3.4.1.4) or destroy the window
• Destroy any internal state associated with the window

If the user aborts the deletion during the confirmation dialog, the client should ignore the message. Clients are permitted to interact with the user and ask, for example, whether a file associated with the window to be deleted should be save or the window deletion should be cancelled. Clients are not required to destroy the window itself; the resource may be reused, but all associated state (for example, backing store) should be released.

If the client aborts a destroy and the user then selects DELETE WINDOW again, the window manager should start the WM_DELETE_WINDOW protocol again. Window managers should not use DestroyWindow requests on a window that has WM_DELETE_WINDOW in its WM_PROTOCOLS property.

Clients that choose not to include WM_DELETE_WINDOW in the WM_PROTOCOLS property may be disconnected from the server if the user asks for one of the client's top-level windows to be deleted.

3.4.2.9 Redirecting Requests

Normal clients can use the redirection mechanism just as window managers do by selecting for SubstructureRedirect events on a parent window or ResizeRedirect events on a window itself. However, at most, one client per window can select for these events, and a convention is needed to avoid clashes.

Convention

Clients (including window managers) should select for SubstructureRedirect and ResizeRedirect events only on windows that they own.

In particular, clients that need to take some special action if they are resized can select for ResizeRedirect events on their top-level windows. They will receive a ResizeRequest event if the window manager resizes their window, and the resize will not actually take place. Clients are free to make what use they like of the information that the window manager wants to change their size, but they must configure the window to the width and height specified in the event in a timely fashion. To ensure that the resize will actually happen at this stage instead of being intercepted and executed by the window manager (and thus restarting the process3, the client needs temporarily to set override-redirect on the window.

Conventions

Clients receiving ResizeRequest events must respond by doing the following:

• Setting override-redirect on the window specified in the event
• Configuring the window specified in the event to the width and height specified in the event as soon as possible and before making any other geometry requests
• Clearing override-redirect on the window specified in the event

If a window manager detects that a client is not obeying this convention, it is free to take whatever measures it deems appropriate to deal with the client.

3.4.3 Communication with the Window Manager by Means of Selections

For each screen they manage, window managers will acquire ownership of a selection named WM_Sn where n is the screen number, as described in Section 3.1.2.6. Window mangers should comply with the conventions for "Manager Selections" described in Section 3.2.8. The intent is for clients to be able to request a variety of information or services by issuing conversion requests on this selection. Window managers should support conversion of the following target on their manager selection:

15) As a special case. clients not wishing to implement d selection request may simply i>sue d GetSelectionOwner request on the appropriate WM_Sn selection. If this selection is owned clients may assume that the window manager complies with ICCCM version 2.() or later.

3.4.4 Summary of Window Manager Property Types

The window manger properties are summarized in the following table (see also Section 14.1 of Xlib-C Language X Interface, Part II of the Xlib Programming Manual).

3.5 SESSION MANAGEMENT

This section contains some conventions for clients that participate in session management. See X Session Management Protocol for further details. Clients that do not support this protocol cannot expect their window state (e.g. WM_STATE, position, size and stacking order) to be preserved across sessions.

3.5.1 Client Support for Session Management

Each session participant will obtain a unique client identifier (client-ID) from the session manager. The client must identify one top level window as the "client leader." This window must be created by the client. It may be in any state, including the Withdrawn state. The client leader window must have a SM_CLIENT_ID property, which contains the client-ID obtained from the session management protocol. That property must:

• be of type STRING;
• be of format 8; and
• contain the client-ID as a string of XPCS characters encoded using ISO 8859-1.

All top-level, non-transient windows created by a client on the same display as the client leader must have a WM_CLIENT_LEADER property. This property contains a window ID that identifies the client leader window. The client leader window must have a WM_CLIENT_LEADER property containing its own window ID (i.e. the client leader window is pointing to itself). Transient windows need not have a WM_CLIENT_LEADER property if the client leader can be determined using the information in the WM_TRANSIENT_FOR property. The WM_CLIENT_LEADER property must:

• be of type WINDOW:
• be of format 32; and
• contain the window ID of the client leader window.

A client must withdraw all of its top level windows on the same display before modifying g either the WM_CLIENT_LEADER or the SM_CLIENT_ID property of its client leader window.

It is necessary that other clients be able to uniquely identify a window (across sessions) among all windows related to the same client-ID. For example, a window manager can require this unique ID to restore geometry information from a previous session, or a workspace manager could use it to restore information about which windows are in which workspace. A client may optionally provide a -WM_WINDOW_ROLE property to uniquely identify a window within the scope specified above. The combination of SM_CLIENT_ID and WM_WINDOW_ROLE can be used by other clients to uniquely identify a window across sessions.

If the WM_WINDOW_ROLE property is not specified on a top level window, a client that needs to uniquely identify that window will try to use instead the values of WM_CLASS and WM_NAME. If a client has multiple windows with identical WM_CLASS and WM_NAME properties, then it should provide a WM_WINDOW_ROLE property.

The client must set the WM_WINDOW_ROLE property to a string that uniquely identifies that window among all windows that have the same client leader window. The property must:

• be of type STRING;
• be of format 8; and
• contain a string restricted to the XPCS characters, encoded in ISO 8859-1.

3.5.2 Window Manager Support for Session Management

A window manger supporting session management must register with the session manager and obtain its own client-ID. The window manger should save and restore information such as the WM_STATE, the layout of windows on the screen, and their stacking order, for every client window that has a valid SM_CLIENT_ID property (on itself, or on the window named by WM_CLIENT_LEADER) and that can be uniquely identified. Clients are allowed to change this state during the first phase of the session checkpoint process. Therefore, window managers should request a second checkpoint phase and save clients' state only during that phase.

3.6 MANIPULATION OF SHARED RESOURCES

X Version 11 permits clients to manipulate a number of shared resources, for example, the input focus, the pointer, and colormaps. Conventions are required so that clients share resources in an orderly fashion.

3.6.1 The Input Focus

Clients that explicitly set the input focus must observe one of two modes:

• Locally active mode
• Globally active mode

  Conventions

  1. Locally active clients should set the input focus to one of their windows only when it is already in one of their windows or when they receive a WM_TAKE_FOCUS message. They should set the input field of the WM_HINTS structure to True.
     
  2. Globally active clients should set the input focus to one of their windows only when they receive a button event and a passive-grabbed key event, or when they receive a WM_TAKE_FOCUS message. They should set the input field of the WM_HINTS structure to False.
  3. In addition, clients should use the timestamp of the event that caused them to attempt to set the input focus as the time field on the SetInputFocus request, not CurrentTime.

3.6.2 The Pointer

In general, clients should not warp the pointer. Window managers, however, may do so (for example, to maintain the invariant that the pointer is always in the window with the input focus). Other window managers may want to preserve the illusion that the user is in sole control of the pointer.

Conventions

1. Clients should not warp the pointer.
2. Clients that insist on warping the pointer should do so only with the src-window argument of the WarpPointer request set to one of their windows.

3.6.3 Grabs

A client's attempt to establish a button or a key grab on a window will fail if some other client has already established a conflicting grab on the same window. The grabs, therefore, are shared resources, and their use requires conventions.

In conformance with the principle that clients should behave, as far as possible, when a window manager is running as they would when it is not, a client that has the input focus may assume that it can receive all the available keys and buttons.

Convention

Window managers should ensure that they provide some mechanism for their clients to receive events from all keys and all buttons, except for events involving keys whose KeySyms are registered as being for window management functions (for example, a hypothetical WINDOW KeySym).

In other words, window managers must provide some mechanism by which a client can receive events from every key and button (regardless of modifiers) unless and until the X Consortium registers some KeySyms as being reserved for window management functions. Currently, no KeySyms are registered for window management functions.

Even so, clients are advised to allow the key and button combinations used to elicit program actions to be modified, because some window managers may choose not to observe this convention or may not provide a convenient method for the user to transmit events from some keys.

Convention

Clients should establish button and key grabs only on windows that they own.

In particular, this convention means that a window manager that wishes to establish a grab over the client's top-level window should either establish the grab on the root, or reparent the window and establish the grab on a proper ancestor. In some cases, a window manager may want to consume the event received, placing the window in a state where a subsequent such event will go to the client. Examples are:

• Clicking in a window to set focus with the click not being offered to the client
• Clicking in a buried window to raise it, again, with the click not offered to the client

More typically, a window manager should add to rather than replace the client's semantics for key+button combinations by allowing the event to be used by the client after the window manager is done with it. To ensure this, the window manager should establish the grab on the parent by using the following:

pointer/keyboard-mode == Synchronous

Then, the window manager should release the grab by using an AllowEvents request with the following specified:

mode== ReplayPointer/Keyboard

In this way, the client will receive the events as if they had not been intercepted.

Obviously, these conventions place some constraints on possible user interface policies. There is a trade-off here between freedom for window managers to implement their user interface policies and freedom for clients to implement theirs. The dilemma is resolved by:

• Allowing window managers to decide if and when a client will receive an event from any given key or button
• Placing a requirement on the window manager to provide some mechanism, perhaps a "Quote" key, by which the user can send an event from any key or button to the client

3.6.4 Colormaps

Section 3.4.1.8 prescribes conventions for clients to communicate with the window manager about their colormap needs. If your clients are DirectColor type applications, you should consult Section l 4.3 of Xlib-C Language X Interface for conventions connected with sharing standard colormaps. They should look for and create the properties described there on the root window of the appropriate screen.

The contents of the RGB_COLOR_MAP type property are as follows:

When deleting or replacing an RGB_COLOR_MAP, it is not sufficient to delete the property; it is important to free the associated colormap resources as well. If kill_id is greater than one, the resources should be freed by issuing a KillClient request with kill_id as the argument. If kill_id is one, the resources should be freed by issuing a FreeColormap request with colormap as the colormap argument. If kill_id is zero, no attempt should be made to free the resources. A client that creates an RGB_COLOR_MAP for which the colormap resource is created specifically for this purpose should set kill_id to one (and can create more than one such standard colormap using a single connection). A client that creates an RGB_COLOR_MAP for which the colormap resource is shared in some way (for example, is the default colormap for the root window) should create an arbitrary resource and use its resource ID for kill_id (and should create no other standard colormaps on the connection).

Convention

If an RGB_COLOR_MAP property is too short to contain the visual_id field, it can be assumed that the visualid is the root visual of the appropriate screen. If an RGB_COLOR_MAP property is too short to contain the kill_id field, a value of zero can be assumed.

During the connection handshake, the server informs the client of the default colormap for each screen. This is a colormap for the root visual, and clients can use it to improve the extent of colormap sharing if they use the root visual.

3.6.5 The Keyboard Mapping

The X server contains a table (which is read by GetKeyboardMapping requests) that describes the set of symbols appearing on the corresponding key for each keycode generated by the server. This table does not affect the server's operations in any way; it is simply a database used by clients that attempt to understand the keycodes they receive. Nevertheless, it is a shared resource and requires conventions.

It is possible for clients to modify this table by using a ChangeKeyboardMapping request. In general, clients should not do this. In particular, this is not the way in which clients should implement key bindings or key remapping. The conversion between a sequence of keycodes received from the server and a string in a particular encoding is a private matter for each client (as it must be in a world where applications may be using different encodings to support different languages and fonts). See the Xlib reference manual for converting keyboard events to text.

The only valid reason for using a ChangeKeyboardMapping request is when the symbols written on the keys have changed as, for example, when a Dvorak key conversion kit or a set of APL keycaps has been installed. Of course, a client may have to take the change to the keycap on trust.

The following illustrates a permissible interaction between a client and a user:

Convention

Clients should not use ChangeKeyboardMapping requests.

If a client succeeds in changing the keyboard mapping table, all clients will receive MappingNotify (request==Keyboard) events. There is no mechanism to avoid receiving these events.

Convention

Clients receiving MappingNotify(request==Keyboard) events should update any internal keycode translation tables they are using.

3.6.6 The Modifier Mapping

X Version 11 supports eight modifier bits of which three are preassigned to Shift, Lock, and Control. Each modifier bit is controlled by the state of a set of keys, and these sets are specified in a table accessed by GetModifierMapping and SetModifierMapping requests. This table is a shared resource and requires conventions.

A client that needs to use one of the preassigned modifiers should assume that the modifier table has been set up correctly to control these modifiers. The Lock modifier should be interpreted as Caps Lock or Shift Lock according as the keycodes in its controlling set include XK_Caps_Lock or XK_Shift_Lock.

Convention

Clients should determine the meaning of a modifier bit from the KeySyms being used to control it.

A client that needs to use an extra modifier (for example, META) should do the following:

• Scan the existing modifier mappings. If it finds a modifier that contains a keycode whose set of KeySyms includes XK_Meta_L or XK_Meta_R, it should use that modifier bit.
• If there is no existing modifier controlled by XK_Meta_L or XK_Meta_R, it should select an unused modifier bit (one with an empty controlling set) and do the following:

-	If there is a keycode with XL_Meta_L in its set of KeySyms, add that keycode to the set for the chosen modifier.
-	If there is a keycode with XL_Meta_R in its set of KeySyms, add that keycode to the set for the chosen modifier.
-	If the controlling set is still empty, interact with the user to select one or more keys to be META.

• If there are no unused modifier bits, ask the user to take corrective action.

Conventions

1. Clients needing a modifier not currently in use should assign keycodes carrying suit able KeySyms to an unused modifier bit.
2. Clients assigning their own modifier bits should ask the user politely to remove his or her hands from the key in question if their SetModifierMapping request returns a Busy status.

There is no good solution to the problem of reclaiming assignments to the five nonpreassigned modifiers when they are no longer being used.

Convention

The user has to use xmodmap or some other utility to deassign obsolete modifier mappings by hand.

When a client succeeds in performing a SetModifierMapping request, all clients will receive MappingNotify(request==Modifier) events. There is no mechanism for preventing these events from being received. A client that uses one of the nonpreassigned modifiers that receives one of these events should do a GetModifierMapping request to discover the new mapping, and if the modifier it is using has been cleared, it should reinstall the modifier.

Note that a GrabServer request must be used to make the GetModifierMapping and SetModifierMapping pair in these transactions atomic.

3.7 DEVICE COLOR CHARACTERIZATION

The X protocol provides explicit RGB values which are used to directly drive a monitor, and color names. RGB values provide a mechanism for accessing the full capabilities of the display device, but at the expense of having the color perceived by the user remain unknowable through the protocol. Color names were originally designed to provide access to a device-independent color database by having the server vendor tune the definitions of the colors in that textual database. Unfortunately, this still does not provide the client anyway of using an existing devicei-ndependent color, nor for the client to get device-independent color information back about colors which it has selected.

Furthermore, the client must be able to discover which set of colors are displayable by the device (the device gamut), both to allow colors to be intelligently modified to fit within the device capabilities (gamut compression) and to enable the user interface to display a representation of the reachable color space to the user (gamut display).

So, a system is needed which will provide full access to device-independent color spaces for X clients. This system should use a standard mechanism for naming the colors, be able to provide names for existing colors, and provide means by which unreachable colors can be modified to fall within the device gamut.

We are fortunate in this area to have a seminal work, the 1931 CIE color standard, which is nearly universally agreed upon as adequate for describing colors on CRT devices. This standard uses a tri-stimulus model called CIE XYZ in which each perceivable color is specified as a triplet of numbers. Other appropriate device independent color models do exist, but most of them are directly traceable back to this original work.

X device color characterization provides device-independent color spaces to X clients. It does this by providing the barest possible amount of information to the client which allows the client to construct a mapping between CIE XYZ and the regular X RGB color descriptions.

Device color characterization is defined by the name and contents of two window properties which, together, permit converting between CIE XYZ space and linear RGB device space (such as standard CRTs). Linear RGB devices require just two pieces of information to completely characterize them:

A 33 matrix M (and it's inverse, M^-1 ) which convert between XYZ and RGB intensity (RGB_intensity):

RGB_intensity = M XYZ
XYZ = M ^-1 RGB_intensity

A way of mapping between RGB intensity and RGB protocol value. XDCCC supports three mechanisms which will be outlined below.

If other device types are eventually necessary, additional properties will be required to describe them.

3.7.1 XYZ RGB Conversion Matrices

Because of the limited dynamic range of both XYZ and RGB intensity, these matrices will be encoded using a fixed point representation of a 32-bit 2s complement number scaled by 2²⁷, giving a range of-16 to 16-, where = 2³⁷.

These matrices will be packed into an 18 element list of 32 bit values, XYZ RGB matrix first, in row major order and stored in the "XDCCC_LINEAR_RGB_MATRICES" properties (format = 32) on the root window of each screen, using values appropriate for that screen.

This will be encoded as:

XDCCC_LINEAR_RGB_MATRICES property contents

Field	Type	Comments
M0,0	INT32	Interpreted as a fixed point number -16<16
M0,1	INT32
. . .
M3.3	INT32
M-1 0,0	INT32
M-1 0,1	INT32
. . .
M-1 3,3	INT32

3.7.2 Intensity RGB value Conversion

XDCCC provides two representations for describing the conversion between RGB intensity and the actual X protocol RGB values:

0	RGB value/RGB intensity level pairs
1	RGB intensity ramp

In both cases, the relevant data will be stored in the "XDCCC_LINEAR_RGB_CORRECTION" properties on the root window of each screen, using values appropriate for that screen, in whatever format provides adequate resolution. Each property can consist of multiple entries concatenated together, if different visuals for the screen require different conversion data. A entry with a VisualID of 0 specifies data for all visuals of the screen that are not otherwise explicitly listed.

The first representation is an array of RGB value/intensity level pairs, with the RGB values in strictly increasing order. When converting, the client must linearly interpolate between adjacent entries in the table to compute the desired value. This is to allow the server to perform gamma correction itself and encode that fact in a short 2 element correction table. The intensity will be encoded as an unsigned number to be interpreted as a value between 0 and 1 (inclusive). The precision of this value will depend on the format of the property in which it is stored (8, 16 or 32 bits). For 16 and 32 bit formats, the RGB value will simply be the value stored in the property. When stored in 8-bit format, the RGB value can be computed from the value in the property by:

Because the three electron guns in the device may not be exactly alike in response characteristics, it is necessary to allow for three separate tables, one each for red, green and blue. So, each table will be preceded by the number of entries in that table, and the set of tables will be preceded by the number of tables. When 3 tables are provided, they will be in red, green, blue order.

This will be encoded as:

XDCCC_LINEAR_RGB_CORRECTION property contents for type 0 correction

Note that the VisualID is stored in 4, 2, or 1 pieces, depending on whether the property format is 8, 16, or 32, respectively. The VisualID is always stored most-significant piece first. Note that the length fields are stored as one less than the actual length, so that 2S6 entries can be stored in format 8

The second representation is a simple array of intensities for a linear subset of RGB values. The expected size of this table is the bits-per-rgb-value of the screen, but it can be any length. This is similar to the first mechanism, except that the RGB value numbers are implicitly defined by the index in the array (indices start at 0):

When converting, the client may linearly interpolate between entries in this table. The intensity values will be encoded just as in the first representation.

This will be encoded as:

XDCCC_LINEAR_RGB_CORRECTION property contents for type 1 correction

3.8 CONCLUSION

3.8.1 The X Registry

The X Consortium maintains a registry for certain X-related items, to aid in avoiding conflicts and to aid in sharing of such items. Readers are encouraged to use the registry. The classes of items kept in the registry that are relevant to the ICCCM include property names, property types, selection names, selection targets, WM_PROTCOLS protocols, ClientMessage types, and application classes. Requests to register items, or questions about registration, should be addressed to

xregistry@ x.org

or to

Registry
X Consortium,
I Memorial Dr
Cambridge MA 02142-1301
USA

Electronic mail will be acknowledged upon receipt. Please allow up to four weeks for a formal response to registration and inquiries.

The registry is published as part of the X software distribution from the X Consortium. All registered items must have the postal address of someone responsible for the item, or a reference to a document describing the item and the postal address of where to write to obtain the document.