rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (01/11/89)
.de Ip .IP \(bu 3 .. .TL X Window System, Version 11 .sp Inter-Client Communication Conventions Manual .sp A Status Report \- January 1989 .AU David S. H. Rosenthal .AI Sun Microsystems, Inc. 2550 Garcia Ave. Mountain View CA 94043 .AB At the 1988 X conference the Inter-Client Communication Conventions Manual was introduced. A preliminary draft was circulated with the X11R2 release, and this draft has been the subject of an extensive and detailed review under the auspices of the Consortium. A revised draft, with many changes, is being released for public review. An introduction to this draft and the review process is provided, and the rationale for the changes discussed. .AE .LP .DS C Copyright \(co 1989 by Sun Microsystems, Inc.\s-2\u*\d\s0 .DE .FS * Permission to use, copy, modify and distribute this document for any purpose and without fee is hereby granted, provided that the above copyright notice and this permission notice appear in all copies, and that the name of Sun Microsystems, Inc. not be used in advertising or publicity pertaining to distribution of the software described herein without specific, written prior permission. Sun Microsystems, Inc. makes no representations about the suitability of the software described herein for any purpose. It is provided "as is" without express or implied warranty. .FE .QP ``in New York, in the control room, the reader is soldered to the chair at the wrists, with pressure manometers and a stethoscopic belt, her temples beneath their crown of hair held fast by the serpentine wires of the encephalogram that mark the intensity of her concentration and the frequency of stimuli. "All our work depends on the sensitivity of the subject at our disposal for the control tests: and it must, moreover, be a person of strong eyesight and nerves, to be subjected to the uninterrupted reading of novels and variants of novels as they are turned out by the computer. If the reading attention reaches certain highs with a certain continuity, the product is viable and can be launched on the market; if attention, on the contrary, relaxes and shifts, the combination is rejected and its elements are broken up and used again in other contexts." The man in the white smock rips off one encephalogram after another after another, as if they were pages from a calendar. "Worse and worse," he says. "Not one novel being produced holds up. Either the programming has to be revised or the reader is not functioning."'' .sp Italo Calvino, \fIIf on a winter's night a traveller\fP .NH Introduction .LP The Inter-Client Communication Conventions Manual (ICCCM) for Version 11 of the X Window System\s-2\u\(dg\d\s0 .FS \(dg The X Window System is a trademark of the Massachusetts Institute of Technology. .FE is being distributed for public review under the auspices of the X Consortium. This document provides some historical context for the ICCCM, describes the mechanism of the review process and some of the constraints that the history has placed upon it, reviews the changes that have been made to the document since the last widely circulated draft, and provides some rationale for them. .NH 2 Pre-History .LP Although the need for some conventions to govern communications between clients sharing the same server was recognized early in the design of X11, the scope and importance of the conventions was not understood until shortly after the X11R1 release, when I undertook to produce the first draft of a manual describing them. I read the protocol specification and the Xlib manuals, and collected a list of questions. After about three months firing questions by electronic mail to everyone I knew involved in window managers and selection services, I was able to assemble a 25-page document in time for it to be reviewed by a meeting at MIT and distributed with the X11R2 release. .LP In retrospect, including this draft in the release was a mistake. Although by that time the need for the document had become obvious and urgent, the rush to put it together had not allowed for detailed review. I, and the unofficial group of reviewers, understood that many parts of the document would require changing, and added warnings to this effect. Nevertheless, in the rush to get both software and books to market people who lacked anything else to work with placed undue importance on this draft, and this in turn placed severe constraints on the Consortium review process. .NH 2 Consortium Review .LP After the X11R2 release a mail alias was set up at MIT and discussion via electronic mail and meetings (at the San Francisco Usenix conference) continued, with the object of developing a draft suitable for review by the X Consortium. This draft, dated 27\u\s-2th\d\s0 July 1988, was then circulated to Consortium members and intensively reviewed by electronic mail. The mail archive for this review is several megabytes, and the document grew from 25 to 45 pages. .NH 2 Public Review .LP A revised draft of the ICCCM is being circulated for public review. The objective of this review is to determine if the current draft is acceptable as a standard. The X community is encouraged to review the draft and submit comments by electronic mail to .I icccm@expo.lcs.mit.edu . Each comment should cover a single topic, and should: .Ip Identify any objectionable wording in the document. .Ip Suggest specific alternative wording. .Ip Provide a rationale for the suggested change. .LP The ICCCM review committee will review the comments mailed to .I icccm (ignoring all others) and work with the commentor to develop a response to any comments they deem to be significant. The comment and response will be combined and published via .I xpert . .LP At the end of the public review period, the Consortium will either: .Ip determine that the draft is acceptable and promulgate it as a Consortium standard (possibly with editorial changes), .Ip or determine that the draft requires technical changes and refer it back for further work by the ICCCM review committee, followed by a further public review. .LP The current state of the document is the result of more than a year's work by a large group of experts directly involved in the development of window managers, selection services, toolkits and client programs. No document of this kind can ever be either finished or perfect; it is inevitably a compromise and in this case many of the compromises have been driven by ``backwards compatibility'' with the X11R2 draft. Further, this document is already much later than would have been desirable. Commentors should therefore take the review process seriously, and carefully distinguish between: .Ip problems that they regard as intolerable and that they would be prepared to delay substantially the promulgation of the document to see corrected, .Ip aspects that they don't like but could live with for a few years until a future revision of the document, .Ip and additional functionality that they can live without in an initial standard but would like to see in a future revision. .NH Changes .LP The revision process identified a number of problems and omissions in the X11R2 draft. The changes that resulted are summarized in this section. .NH 2 Window States .LP The X11R2 draft described top-level windows as being in one of a number of states, for example .I ClientIconState or .I IgnoreState . It turned out to be difficult to specify semantics for these states and reliable mechanisms to change state. As a result, the set of states has been simplified and the mechanisms for changing between states redefined. .LP From the client's point of view, the window manager will regard each of the client's top-level non-override-redirect windows as being in one of three states. The semantics of the states are: .Ip NormalState. The client's top-level window is visible. .Ip 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. .Ip WithdrawnState. Neither the client's top-level window nor its icon are visible. .LP Newly-created top-level windows are in Withdrawn state. Once the window has been provided with suitable properties, the client is free to change its state as follows: .Ip Withdrawn \(-> Normal. The client should map the window with WM_HINTS.initial_state being NormalState. .Ip Withdrawn \(-> Iconic. The client should map the window with WM_HINTS.initial_state being IconicState. .Ip Normal \(-> Iconic. The client should send a client message event to the root window with ``type'' WM_CHANGE_STATE. .Ip Normal \(-> Withdrawn. The client should unmap the window, and follow it with a synthetic UnmapNotify event to the root window. .Ip Iconic \(-> Normal. The client should map the window. The contents of WM_HINTS.initial_state are irrelevant in this case. .Ip Iconic \(-> Withdrawn. The client should unmap the window, and follow it with a synthetic UnmapNotify event as above. .LP Once a client's non-override-redirect top-level window has left Withdrawn state, the client will know that the window is in Normal state if it is mapped, and that the window is in Iconic state if it is not mapped. .NH 2 Window Size & Location .LP Clients adhering to the X11R2 draft specified the size and location of their top-level windows by setting fields in the WM_NORMAL_HINTS property. Of course, they also had to provide values for the size and location attributes of the window, but these were ignored if a window manager was running. This was regarded as clumsy and error-prone, and was abandoned. Clients now specify the size and location of their top-level windows as they would if there were no window manager. .NH 2 Colormaps .LP The X11R2 draft described a mechanism by which window managers and clients cooperated to install colormaps. The lack of protocol support for avoiding the race conditions in installing colormaps meant that this mechanism could not be implemented reliably, and the mechanism also mandated some features of the look-and-feel. As a result the conventions have been changed to forbid clients installing their own colormaps. A property called WM_COLORMAP_WINDOWS is used to tell the window manager the colormaps the client wants installed. .NH 2 Pseudo-Root Support .LP The X11R2 draft specified a pseudo-root mechanism. Although it was successfully implemented and used by several groups, experience has shown that it cannot support all the uses envisaged. An extension will be required and, in order to leave room for the design of this extension pseudo-root support has been removed from the conventions. .NH 2 Top-level Window Gravity .LP In the X11R2 draft, windows were always positioned by specifying the top-left corner. Clients could not achieve reliable positioning, since they did not know the width of the decorations the window manager was providing. A ``win-gravity'' field has been added to the WM_NORMAL_HINTS property to avoid this problem. .NH 2 WM_PROTOCOLS .LP The ``messages'' field of the WM_HINTS property was found to be unwieldy and difficult to evolve. It has been replaced with a WM_PROTOCOLS property specifying the ClientMessage events that clients may receive from the window manager, and the format of these messages has been unified. .NH 2 WM_CONFIGURE_DENIED & WM_WINDOW_MOVED .LP As part of this change, the ClientMessage events specified in the X11R2 draft that notified clients about certain window manager actions that would not generate automatic notification events have been removed. Window managers must now generate these notification events synthetically, simplifying client programs considerably. .NH 2 WM_STATE .LP The WM_STATE property described in the X11R2 draft is unchanged, but its use has been clarified. In particular, normal clients should never inspect its contents which are for communication between window and session managers only. .NH 2 Client Termination & Window Deletion .LP The protocol by which clients request notification of impending termination from the session manager has changed, partly as a result of the WM_PROTOCOLS change, partly because the name BANG! was thought insufficiently serious, and partly to avoid problems with multi-top-level window clients. .LP A protocol (WM_DELETE_WINDOW) by which a session manager can request a client with multiple top-level windows to delete one of them has been added. .NH 2 Selection Mechanisms .LP A number of detailed changes have been made to the selection mechanism, mostly to avoid race conditions. The protocols for large data transfers and for the CLIPBOARD selection are the most important of these. .LP Support for selection targets with side-effects has been added, allowing operations such as ``exchange PRIMARY and SECONDARY selections''. .NH 2 TEXT properties .LP In order to support multiple languages by supporting multiple font encodings, the semantics of STRING and TEXT properties have been clarified. .LP Properties with type STRING are now assumed to be encoded in ISO Latin 1 (which does not include control characters) with the addition of the TAB and NEWLINE control characters (but no others). .LP Other encodings are specified by other type Atoms. The Consortium will maintain a registry of these encoding type Atoms, which will in general match the ``encoding'' field in the font naming scheme. .NH 2 Cut-Buffers .LP The section describing cut-buffer conventions has been added. In general, clients are encouraged to use the selection mechanism instead. .NH Incompatibilities .LP During the revision we have been very careful not to introduce gratuitous incompatibility. A far as possible, we have tried to ensure that clients obeying the conventions in the X11R2 draft would still work. .LP The areas in which incompatibilities have become necessary are: .Ip The use of property None in ConvertSelection requests is no longer allowed, to avoid some race conditions. Owners receiving them are free to use the target atom as the property to respond with, which will work in most cases. .Ip The protocol for INCREMENTAL type properties as selection replies has changed to avoid race conditions, and the name has been changed to INCR. Selection requestors are free to implement the earlier protocol if they receive properties of type INCREMENTAL. .Ip The protocol for INDIRECT type properties as selection replies has changed, and the name has been changed to MULTIPLE. Selection requestors are free to implement the earlier protocol if they receive properties of type INDIRECT. .Ip The protocol for the special CLIPBOARD client has changed. The earlier protocol is subject to race conditions, and should not be used. .Ip The set of state values in WM_HINTS.initial_state has been reduced, but the values that are still valid are unchanged. Window managers should treat the other values sensibly. .Ip The methods an application uses to change the state of its top-level window have changed, but in such a way that cases that used to work will still work. .Ip The ``x'', ``y'', ``width'', and ``height'' fields have been removed from the WM_NORMAL_HINTS property, and replaced by pad fields. Values set into these fields will be ignored. The position and size of the window should be set by setting the appropriate window attributes. .Ip A ``win_gravity'' field has been added to the WM_NORMAL_HINTS property. Window managers will assume a compatible value if the client sets a short property. .Ip The ``messages'' field of the WM_HINTS property has been replaced by the WM_PROTOCOLS property, but clients using the earlier mechanism can be detected because they set the ``messages'' bit in the flags field of the WM_HINTS property and window managers can provide a backwards-compatibility mode. .Ip The mechanism described in the earlier draft by which clients installed their own sub-window colormaps has been replaced by the WM_COLORMAP_WINDOWS property. Clients using the earlier mechanism can be detected by the WM_COLORMAPS property they set on their top-level window, but providing a reliable backwards compatibility mode is not possible. .Ip The pseudo-root facility in the earlier draft has been removed. In general, the previous mechanism was invisible to clients and no incompatibility should result. .Ip The document's epigraph has been changed. The new epigraph is more functional than its predecessor, but it is not backwards compatible. .Ip The addition of the WM_DELETE_WINDOW protocol (which prevents the danger that multi-window clients may be terminated unexpectedly) has meant some changes in the BANG! (now called WM_SAVE_YOURSELF) protocol, to ensure that the two protocols are orthogonal. Clients using the earlier protocol can be detected and supported in a backwards-compatibility mode. .Ip The conventions in Section 9.2.2. of the Xlib manual regarding properties of type RGB_COLOR_MAP have been changed, but clients using the earlier conventions can be detected because their properties are 4 bytes shorter. They will work correctly if the server supports only a single Visual, or if they use only the Visual of the root. These are the only cases in which they would have worked, anyway. .NH Conclusion .LP A long and detailed review process has made major improvements to the conventions for communicating between X11 clients. In most cases, these improvements have been made in ways which allow clients based on the earlier draft conventions to be supported. .SH Acknowledgements .LP Thanks are due to everyone who contributed to the reviews over the past year, and especially to the following: .Ip For the Selection section, Jerry Farrell, Phil Karlton, Mark Manasse, Loretta Guarino Reid, and Bob Scheifler. .Ip For the Cut-Buffer section, Andrew Palay. .Ip For the Window and Session Manager sections, Todd Brunhoff, Ellis Cohen, Jim Fulton, Hania Gajewska, Jordan Hubbard, Audrey Ishizaki, Kerry Kimbrough, Matt Landau, Mark Manasse, Bob Scheifler, Ralph Swick, Mike Wexler, and Glenn Widener.