0 ,li~d j"Tr.\Jbѿ e_I|? The XFIXES Extension Version 5.0 Document Revision 1 2010-11-15 Keith Packard keithp@keithp.com 1. Introduction X applications have often needed to work around various shortcomings in the core X window system. This extension is designed to provide the minimal server-side support necessary to eliminate problems caused by these workarounds. 2. Acknowledgements This extension is a direct result of requests made by application developers, in particular, + Owen Taylor for describing the issues raised with the XEMBED mechanisms and SaveSet processing and his initial extension to handle this issue, and for pointer barriers + Bill Haneman for the design for cursor image tracking. + Havoc Pennington + Fredrik Höglund for cursor names + Deron Johnson for cursor visibility 3. Basic Premise Requests in this extension may seem to wander all over the map of X server capabilities, but they are tied by a simple rule -- resolving issues raised by application interaction with core protocol mechanisms that cannot be adequately worked around on the client side of the wire. 4. Extension initialization The client must negotiate the version of the extension before executing extension requests. Behavior of the server is undefined otherwise. QueryVersion client-major-version: CARD32 client-minor-version: CARD32 -> major-version: CARD32 minor-version: CARD32 The client sends the highest supported version to the server and the server sends the highest version it supports, but no higher than the requested version. Major versions changes can introduce new requests, minor version changes introduce only adjustments to existing requests or backward compatible changes. It is the clients responsibility to ensure that the server supports a version which is compatible with its expectations. ************* XFIXES VERSION 1 OR BETTER *********** 5. Save Set processing changes Embedding one application within another provides a way of unifying disparate documents and views within a single framework. From the X protocol perspective, this appears similar to nested window managers; the embedding application "manages" the embedded windows much as a window manager does for top-level windows. To protect the embedded application from embedding application failure, it is reasonable to use the core SaveSet mechanism so that embedding application failure causes embedded windows to be preserved instead of destroyed. The core save set mechanism defines the target for each save set member window as the nearest enclosing window not owned by the terminating client. For embedding applications, this nearest window is usually the window manager frame. The problem here is that the window manager will not generally expect to receive and correctly manage new windows appearing within that window by the save set mechanism, and will instead destroy the frame window in response to the client window destruction. This causes the embedded window to be destroyed. An easy fix for this problem is to change the target of the save set member to a window which won't be affected by the underlying window destruction. XFIXES chooses the root window as the target. Having embedded windows suddenly appear at the top level can confuse users, so XFIXES also lets the client select whether the window should end up unmapped after the save set processing instead of unconditionally making them be mapped. 5.1 Requests ChangeSaveSet window: Window mode: { Insert, Delete } target: { Nearest, Root } map: { Map, Unmap } ChangeSaveSet is an extension of the core protocol ChangeSaveSet request. As in that request, mode specifies whether the indicated window is inserted or deleted from the save-set. Target specifies whether the window is reparented to the nearest non-client window as in the core protocol, or reparented to the root window. Map specifies whether the window is mapped as in the core protocol o