From 016e26badad2e506a67c8122d97b773eb1ca737c Mon Sep 17 00:00:00 2001 From: hp Date: Sun, 23 Apr 2000 16:48:28 +0000 Subject: Initial revision --- wm-spec/wm-spec.sgml | 672 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 672 insertions(+) create mode 100644 wm-spec/wm-spec.sgml diff --git a/wm-spec/wm-spec.sgml b/wm-spec/wm-spec.sgml new file mode 100644 index 0000000..2ac6702 --- /dev/null +++ b/wm-spec/wm-spec.sgml @@ -0,0 +1,672 @@ + +
+ +Extended Window Manager Hints +15 March 2000 + + + Introduction + + What is this spec? + +This spec defines interactions between window managers, applications and the utilities that form part of a desktop environment. It builds on the ICCCM, which defines wm/client interactions at a lower level. It was born out of a need to replace the original Gnome WM specification, although this specification has been designed to be independent of any one desktop environment. + + + + Language used in this specification + +The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", +"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be +interpreted as described in RFC 2119. + + +The key words "Window Manager" refer to a window manager which is adopting this +specification. "Pager" refers to desktop utility applications, including +pagers and taskbars. "Application" refers to other clients. "Clients" refers +to Pagers + Applications ie. all X clients, except for the Window Manager. + + + + Changes since 1.9d + + +Added _NET_VIRTUAL_ROOTS + + +Added note about ICCCM compliant window moves. + + +Added _NET_WM_HANDLED_ICONS + + +Added _NET_SUPPORTING_WM_CHECK + + +Removed degrees of activation + + + + + Changes since 1.9c + + + +Removed packaging of hints into 2 X properties. Jim Gettys points out that the +performance gains of fewer round trips can be better achieved using Xlib +routines. + + + + +Clarified that _NET_DESKTOP_VIEWPORT is in pixels + + + + +_NET_DESKTOP_VIEWPORT is now an array, one for each desktop, to allow for +different active viewports on different desktops + + + + +_NET_WM_STRUT now only applies on desktops on which the client is visible + + + + +Introduced RFC 2119 language, and attempted to clarify the roles of the Window +Manager, Pagers and Applications + + + + +Added _NET_WM_NAME + + + + +_NET_DESKTOP_NAMES now in UTF8 + + + + +Desktops now start from 0 + + + + +Added _NET_WM_PID + + + + +Added _NET_WM_PING protocol + + + + +Added _NET_WM_STATE_SKIP_TASKBAR + + + + + + + Changes since 1.9b + + Removed _NET_NUMBER_OF_DESKTOPS client message, as it overlaps unnecessarily with _NET_{INSERT/DELETE}_DESKTOP. + + Replaced _NET_WM_LAYER and _NET_WM_HINTS with _NET_WM_WINDOW_TYPE functional hint. + Changed _NET_WM_STATE to a list of atoms, for extensibility. + Expanded description of _NET_WORKAREA and _NET_WM_STRUT. + Removed _NET_WM_SIZEMOVE_NOTIFY protocol. + Added degrees of activation to _NET_ACTIVE_WINDOW client message + Added _NET_WM_ICON + My comments are in [[ ]]. Comments from Marko's draft are in [[MM: ]] + + + + + Root Window Properties (+Related Messages) + _NET_SUPPORTED + + +This property MUST be set by the Window Manager to indicate which hints it +supports. This assumes that backwards incompatible changes will not be made +to the hints (without being renamed). + + _NET_CLIENT_LIST + + +An array of all X Windows managed by the Window Manager. _NET_CLIENT_LIST has +mapping order. _NET_CLIENT_LIST_STACKING has stacking order. This property +SHOULD be set and updated by the Window Manager. + + + + _NET_NUMBER_OF_DESKTOPS + + +This property SHOULD be set and updated by the Window Manager to indicate the +number of virtual desktops. + + +A Pager can insert or delete a certain desktop by sending a +_NET_{INSERT/DELETE}_DESKTOP client message to the root window. + + + + + _NET_DESKTOP_GEOMETRY + + +Array of two cardinals that defines the width and height of each desktop in +pixels. This property SHOULD be set by the Window Manager. + + +A Pager can change the desktop geometry by sending a _NET_DESKTOP_GEOMETRY client +message to the root window + + + + + _NET_DESKTOP_VIEWPORT + + +Array of two cardinals that define the top left corner of the current view in +pixel, for each desktop. For window managers that don't support paged +desktops, this MUST always be set to (0,0). + + +A Pager can change the viewport for the current desktop by sending a +_NET_DESKTOP_VIEWPORT client message to the root window + + + _NET_CURRENT_DESKTOP + , CARDINAL[1]/32 +]]> + +The index of the current desktop, starts with desktop 0. This MUST be set and +updated by the Window Manager If a Pager wants to switch to another virtual +desktop, it MUST send a _NET_CURRENT_DESKTOP client message to the root window +(type _NET_CURRENT_DESKTOP, format 32, l[0]=<new index>) + + _NET_DESKTOP_NAMES + + +The names of all virtual desktops in UTF8 encoding. This property MAY be +changed by a Pager or the Window Mangaer at any time. When a desktop is added +or removed, the Window Manager MUST update this list. + + _NET_ACTIVE_WINDOW + + +The window handle of the currently active window. This is a read-only +property set by the Window Manager. This is a read-only property set by the +window manager. If a client (for example, a taskbar) wants to activate +another window, it MUST send a _NET_ACTIVE_WINDOW client message to the root +window (type _NET_ACTIVE_WINDOW, format 32, l[0]=0 +/* may be used later */, window is the respective client window) + + _NET_WORKAREA + + + + This property MUST be set by WM upon calculating the work area for each desktop (the first quadruple = desktop 1). Contains the left, right, top, bottom co-ordinates for each desktop. Work area SHOULD be used by desktop applications to place desktop icons apropriately. + + + The window manager SHOULD calculate this space by taking the current page minus space occupied by dock and panel windows, as indicated by the _NET_WM_STRUT property set on client windows. + + + + _NET_SUPPORTING_WM_CHECK + + +The Window Manager MUST set this property on the root window to be the ID of a child window created by the WM, to indicate that a compliant WM is active. The child window MUST also have the _NET_SUPPORTING_WM_CHECK property set with the same value. The child window MUST also have the _NET_WM_NAME property set to the name of the Window Manager. + + +Rationale: The child window is used to guard against stale properties being left on the root window by a crashed WM. + + + + _NET_VIRTUAL_ROOTS + + +The Window Manager MUST set this to a list of IDs for windows that are acting as virtual root windows. To implement virtual desktops, some window managers reparent client windows to a child of the root window. The property is present so that Pagers can determine which windows to watch for substructure notifies. + + + + + Other Root Window Messages + _NET_CLOSE_WINDOW + + + Pagers wanting to close a window MUST send a _NET_CLOSE_WINDOW client message request to the root window (type _NET_ACTIVE_WINDOW, format 32, l[0]=0 /*may be used later*/, window should be set to the window to close). The Window Manager MUST then attempt to close the window specified. + + + Rationale: A window manager might be more clever than the usual method (send WM_DELETE message if the protocol is selected, XKillClient otherwise). It might introduce a timeout, for example. Instead of duplicating the code, the Window Manager can easily do the job. + + _NET_WM_MOVERESIZE + + + This message allows an application to initiate window movement or resizing. This allows the application to define its own move and size "grips", whilst letting the window manager control the actual move/resize. This means that all moves / resizes can happen in a consistent manner as defined by the WM. + + + When sending this message, x_root and y_root SHOULD indicate the position of the mouse click [[PDW: with respect to what?]] and direction MUST indicate whether this is a move or resize event, and if it is a resize event, which edges of the window the size grip applies to. + + + + [[PDW: Why do we need to indicate the direction? The WM could guess this from the click position - some WMs (eg. sawmill) have code for doing something similar when you hold eg. Meta + click in the client area... ]] + + + + + Application Window Properties + _NET_PROPERTIES + + +Enables only use of listed properties on this windows. If this property is +set, the Window Manager MUST only handle (XGetWindowProperty) properties +listed here. This property MUST be set by the Client before any other _NET +hints can be used. If this property is set, it MUST also include any ICCCM +client-only (not WM_STATE) hints that are set by the client. If WM_PROTOCOLS +is not listed here, the Window Manager SHOULD assume that it contains exactly +WM_DELETE_WINDOW. + + +This is a performance optimization. [[MM: I still have to do a benchmark.]] + + + _NET_WM_NAME + + +The Client SHOULD set this to the title of the window in UTF8 encoding. If +set, the Window Manager should use this in preference to WM_NAME. + + + _NET_WM_DESKTOP + , CARDINAL/32 +]]> + +Cardinal to determine the desktop the window is in (or wants to be) starting +with 0 for the first desktop. A Client MAY choose not to set this property, +in which case the Window Manager SHOULD place as it wishes. 0xFFFFFFFF +indicates that the window SHOULD appear on all desktops/workspaces. + + +The Window Manager should honor _NET_WM_DESKTOP whenever a withdrawn window +requests to be mapped. + + +A Client can request a change of desktop for a non-withdrawn window by sending +a _NET_WM_DESKTOP client message to the root window (window is the respective +window, type _NET_WM_DESKTOP, format 32, l[0]=<desktop>) + + + The Window Manager MUST keep this property updated on all windows. + + _NET_WM_WINDOW_TYPE + + +This MUST be set by the Client before mapping, to a list of atoms indicating +the functional type of the window. This property SHOULD be used by the window +manager in determining the decoration, stacking position and other behaviour +of the window. The Client SHOULD specify window types in order of preference +(the first being most preferable), but MUST include at least one of the basic +window type atoms from the list below. This is to allow for extension of the +list of types, whilst providing default behaviour for window managers that do +not recognise the extensions. + + +Rationale: This hint is intend to replace the MOTIF hints. One of the +objections to the MOTIF hints is that they are a purely visual description of +the window decoration. By describing the function of the window, the window +manager can apply consistent decoration and behaviour to windows of the same +type. Possible examples of behaviour include keeping dock/panels on top or +allowing pinnable menus / toolbars to only be hidden when another window has +focus (NextStep style). + + + +_NET_WM_WINDOW_TYPE_DESKTOP indicates a desktop feature. This can include a +single window containing desktop icons with the same dimensions as the screen, +allowing the desktop environment to have full control of the desktop, without +the need for proxying root window clicks. + + +_NET_WM_WINDOW_TYPE_DOCK indicates a dock or panel feature. Typically a +window manager would keep such windows on top of all other windows. + + +_NET_WM_WINDOW_TYPE_TOOLBAR and _NET_WM_WINDOW_TYPE_MENU indicate toolbar and +pinnable menu windows, respectively. + + +_NET_WM_WINDOW_TYPE_DIALOG indicates that this is a dialog window. If +_NET_WM_WINDOW_TYPE is not set, then windows with WM_TRANSIENT_FOR set MUST +be taken as this type. + + +_NET_WM_WINDOW_TYPE_NORMAL indicates that this is a normal, top-level window. +Windows with neither _NET_WM_WINDOW_TYPE nor WM_TRANSIENT_FOR are set MUST +be taken as this type. + + + + _NET_WM_STATE + + +A list of hints describing the state window. The Window Manager SHOULD honor +_NET_WM_STATE whenever a withdrawn window requests to be mapped. A Client +wishing to change the state of a window MUST send a _NET_WM_STATE client +message to the root window (see below). The Window Manager MUST keep this +property updated to reflect the current state of the window. + + +Possible atoms are: + + + +_NET_WM_STATE_MODAL indicates that this is a modal dialog box. The +WM_TRANSIENT_FOR hint MUST be set to indicate which window the dialog is a +modal for, or set to the root window if the dialog is a modal for its window +group. + + +_NET_WM_STATE_STICKY indicates that the Window Manager SHOULD keep the +window's position fixed on the screen, even when the virtual desktop scrolls. + + +_NET_WM_STATE_MAXIMIZED_{VERT,HORZ} indicates that the window is +{vertically,horizontally} maximised. + + +_NET_WM_STATE_SHADED indicates that the window is shaded. + + +_NET_WM_SKIP_TASKBAR indicates that a window should not be included on a +taskbar. + + +To change the state of a mapped window, a Client MUST send a _NET_WM_STATE +client message to the root window (window is the respective window, type +_NET_WM_STATE, format 32, l[0]=<the action, as listed below>, +l[1]=<First property to alter>, l[2]=<Second property to alter>). +This message allows two properties to be changed simultaneously, specifically +to allow both horizontal and vertical maximisation to be altered together. +l[2] MUST be set to zero if only one property is to be changed. l[0], the +action, MUST be one of: + + + + See also the implementation notes on urgency and fixed size windows. + + _NET_WM_STRUT + + +This property MUST be set by the Client if the window is to reserve space at +the edge of the screen. The property is a 4-tupel of cardinals, one for each +border of the screen. The order of the borders is left, right, top, bottom. +The client MAY change this property anytime, therefore the Window Manager MUST +watch out for property notify events. + + +The purpose of struts is to reserve space at the borders of the desktop. This +is very useful for a docking area, a taskbar or a panel, for instance. The +window manager should know about this reserved space in order to be able to +preserve the space. Also maximized windows should not cover that reserved +space. + + +Rationale: A simple "do not cover" hint is not enough for dealing with e.g. +auto-hide panels. + + +Notes: An auto-hide panel SHOULD set the strut to be its minimum, hidden size. +A "corner" panel that does not extend for the full length of a screen border +SHOULD only set one strut. + + _NET_WM_ICON_GEOMETRY + + +An array of x,y,w,h of type CARDINAL, format 32. This optional property MAY +be set by standalone tools like a taskbar or an iconbox. It specifies the +geometry of a possible icon in case the window is iconified. + + +Rationale: This makes it possible for a window manager to display a nice +animation like morphing the window into its icon. + + + + _NET_WM_ICON + + +This is an array of possible icons for the client. This specification does +not stipulate what size these icons should be, but individual desktop +environments or toolkits may do so. The Window Manager MAY scale any of these +icons to an appropriate size. + + +This is an array of 32bit packed CARDINAL ARGB with high byte being A, low +byte being B. First two bytes are width, height. Data is in rows, left to +right and top to bottom. + + + + _NET_WM_PID + + +If set, this property MUST contain the process ID of the client owning this +window. This MAY be used by the Window Manager to kill windows which do not +respond to the _NET_WM_PING protocol. + + + _NET_WM_HANDLED_ICONS + + +This property can be set by clients to indicate that the Window Manager need +not provide icons for iconified windows, for example if the client is a taskbar +and provides buttons for iconified windows. + + + + + Window Manager Protocols + + _NET_WM_PING + +This protocol allows the Window Manager to determine if the Client is still +processing X events. This can be used by the Window Manager to determine if a +window which fails to close after being sent WM_DELETE_WINDOW has stopped +responding, or has stalled for some other reason, such as waiting for user +confirmation. A Client SHOULD indicate that it is willing to participate in +this protocol by listing _NET_WM_PING in the WM_PROTOCOLS property of the +client window. + + +A Window Manager can use this protocol at any time by sending a client message +as follows: + + +message_type = WM_PROTOCOLS +format = 32 +data.l[0] = _NET_WM_PING +data.l[1] = +]]> + +A participating Client receiving this message MUST send it back to the root +window immediately, by setting window = root, and calling XSendEvent. The +Client MUST NOT alter the timestamp, as this can be used by the Window Manager +to uniquely identify the ping. + + +The Window Manager MAY kill the Client (using _NET_WM_PID) if it fails to +respond to this protocol within a reasonable time. + + + + + Implementation notes + + 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. + + + + 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). + + +Several GNOME file manager developers have accepted this model + + + + 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. + + + + 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. + + + + 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. + + + + Pagers and Taskbars + + This specification attempts to make reasonable provisions for WM independant pagers and taskbars. Window Managers that require / desire additional functionality beyond what can be acheived 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. + + + + Window Movement + +According to the ICCCM, applications should not see unnecessary differences +between running with or without a window manager. Therefore window movements +for already mapped windows, such as ones requested by XMoveWindow(Display, +Window, X, Y) have to move the window Window to the coordinates (X, Y) and not +cause the window's window manager frame window to end up at (X, Y). + + + + + 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 a 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 the next revision of this specification. + + + +
-- cgit v1.2.3-54-g00ecf From d7b2bbf69a49e852288529a0ea7be4428e433a37 Mon Sep 17 00:00:00 2001 From: hp Date: Sun, 23 Apr 2000 17:27:00 +0000 Subject: commit --- wm-spec/wm-spec.sgml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/wm-spec/wm-spec.sgml b/wm-spec/wm-spec.sgml index 2ac6702..130c302 100644 --- a/wm-spec/wm-spec.sgml +++ b/wm-spec/wm-spec.sgml @@ -1,6 +1,6 @@ -
+
Extended Window Manager Hints 15 March 2000 -- cgit v1.2.3-54-g00ecf From f42a5770bfb86bf78b8dfdb8a49bc1e4281878a9 Mon Sep 17 00:00:00 2001 From: hp Date: Thu, 6 Jul 2000 05:39:54 +0000 Subject: Changes collated by Julian Adams. --- wm-spec/wm-spec.sgml | 89 +++++++++++++++++++++++++++++++++------------------- 1 file changed, 56 insertions(+), 33 deletions(-) diff --git a/wm-spec/wm-spec.sgml b/wm-spec/wm-spec.sgml index 130c302..ee86622 100644 --- a/wm-spec/wm-spec.sgml +++ b/wm-spec/wm-spec.sgml @@ -7,6 +7,12 @@ Introduction + + Version + +This spec is version 1.9f. + + What is this spec? @@ -27,6 +33,26 @@ pagers and taskbars. "Application" refers to other clients. "Clients" refers to Pagers + Applications ie. all X clients, except for the Window Manager. + + Changes since 1.9e + + +Added _NET_WM_VISIBLE_NAME_STRING + + +Removed ambiguity from _NET_NUMBER_OF_DESKTOPS and _NET_DESKTOP_NAMES in combination. + + +Set _NET_WM_MOVERESIZE format to 32 for consistency. + + +Removed _NET_PROPERTIES. + + +Removed comment from _NET_WM_MOVERESIZE. + + + Changes since 1.9d @@ -159,16 +185,21 @@ This property SHOULD be set and updated by the Window Manager to indicate the number of virtual desktops. -A Pager can insert or delete a certain desktop by sending a -_NET_{INSERT/DELETE}_DESKTOP client message to the root window. +A Pager can request change in the desktops number by sending a _NET_SET_NUMBER_OF_DESKTOPS message to the root window: - _NET_DESKTOP_GEOMETRY @@ -219,8 +250,7 @@ _NET_DESKTOP_NAMES ]]> The names of all virtual desktops in UTF8 encoding. This property MAY be -changed by a Pager or the Window Mangaer at any time. When a desktop is added -or removed, the Window Manager MUST update this list. +changed by a Pager or the Window Mangaer at any time. _NET_ACTIVE_WINDOW This message allows an application to initiate window movement or resizing. This allows the application to define its own move and size "grips", whilst letting the window manager control the actual move/resize. This means that all moves / resizes can happen in a consistent manner as defined by the WM. @@ -307,39 +337,32 @@ _NET_WM_MOVERESIZE #define _NET_WM_MOVERESIZE_SIZE_LEFT 7 #define _NET_WM_MOVERESIZE_MOVE 8 /* Movement only */ ]]> - - [[PDW: Why do we need to indicate the direction? The WM could guess this from the click position - some WMs (eg. sawmill) have code for doing something similar when you hold eg. Meta + click in the client area... ]] - Application Window Properties - _NET_PROPERTIES + _NET_WM_NAME -Enables only use of listed properties on this windows. If this property is -set, the Window Manager MUST only handle (XGetWindowProperty) properties -listed here. This property MUST be set by the Client before any other _NET -hints can be used. If this property is set, it MUST also include any ICCCM -client-only (not WM_STATE) hints that are set by the client. If WM_PROTOCOLS -is not listed here, the Window Manager SHOULD assume that it contains exactly -WM_DELETE_WINDOW. - - -This is a performance optimization. [[MM: I still have to do a benchmark.]] +The Client SHOULD set this to the title of the window in UTF8 encoding. If +set, the Window Manager should use this in preference to WM_NAME. - _NET_WM_NAME + + _NET_WM_VISIBLE_NAME_STRING -The Client SHOULD set this to the title of the window in UTF8 encoding. If -set, the Window Manager should use this in preference to WM_NAME. +If the Window Manager displays a window name other than _NET_WM_NAME the Window Manager MUST set this to the title displayed in UTF8 encoding. + +Rationale: For window managers that display a title different from the _NET_WM_NAME or WM_NAME of the window (i.e. xterm <1>, xterm <2>, ... is shown, but _NET_WM_NAME / WM_NAME is still xterm for each window). This property allows taskbars / pagers to display the same title as the window manager. + + _NET_WM_DESKTOP , CARDINAL/32 -- cgit v1.2.3-54-g00ecf From fbc02607dcf70c8fa29eb03c0f49b1623d086867 Mon Sep 17 00:00:00 2001 From: hp Date: Mon, 17 Jul 2000 17:31:54 +0000 Subject: new version from Julian (1.0pre1) --- wm-spec/wm-spec.sgml | 113 ++++++++++++++++++++++++++++++++++++++++++++++----- 1 file changed, 103 insertions(+), 10 deletions(-) diff --git a/wm-spec/wm-spec.sgml b/wm-spec/wm-spec.sgml index ee86622..172f14b 100644 --- a/wm-spec/wm-spec.sgml +++ b/wm-spec/wm-spec.sgml @@ -10,7 +10,7 @@ Version -This spec is version 1.9f. +This spec is version 1.0pre1. @@ -33,6 +33,44 @@ pagers and taskbars. "Application" refers to other clients. "Clients" refers to Pagers + Applications ie. all X clients, except for the Window Manager. + + Prerequisites for adoption of this specification + +Window Managers and Clients which aim to fulfil this specification MUST adhere +to the ICCCM on which this specification builds. If this specification +explicitly modifies the ICCCM Window Managers and Clients MUST fulfil these +modifications. + + + + Changes since 1.9f + + +Revised revision number for first accepted release 1.9XX -> 1.0preXX. + + +Prerequisites for adoption of this specification added. + + +Tidied formatting of _NET_CURRENT_DESKTOP for consistency. + + +Tidied formatting of _NET_ACTIVE_WINDOW for consistency. Removed doubled text. + + +Tidied formatting of _NET_WM_DESKTOP for consistency. + + +Killing Hung Processes implementation note added. _NET_WM_PID and _NET_WM_PING now link to this. + + +Clarified x_root and y_root meaning for _NET_WM_MOVERESIZE. + + +Added contributor list. + + + Changes since 1.9e @@ -241,9 +279,14 @@ _NET_CURRENT_DESKTOP , CARDINAL[1]/32 The index of the current desktop, starts with desktop 0. This MUST be set and updated by the Window Manager If a Pager wants to switch to another virtual -desktop, it MUST send a _NET_CURRENT_DESKTOP client message to the root window -(type _NET_CURRENT_DESKTOP, format 32, l[0]=<new index>) +desktop, it MUST send a _NET_CURRENT_DESKTOP client message to the root window: + _NET_DESKTOP_NAMES -The window handle of the currently active window. This is a read-only -property set by the Window Manager. This is a read-only property set by the +The window handle of the currently active window. This is a read-only property +set by the window manager. If a client (for example, a taskbar) wants to activate another window, it MUST send a _NET_ACTIVE_WINDOW client message to the root -window (type _NET_ACTIVE_WINDOW, format 32, l[0]=0 -/* may be used later */, window is the respective client window) +window: + _NET_WORKAREA - When sending this message, x_root and y_root SHOULD indicate the position of the mouse click [[PDW: with respect to what?]] and direction MUST indicate whether this is a move or resize event, and if it is a resize event, which edges of the window the size grip applies to. + When sending this message, x_root and y_root MUST indicate the position of the mouse click with respect to the root window and direction MUST indicate whether this is a move or resize event, and if it is a resize event, which edges of the window the size grip applies to. A Client can request a change of desktop for a non-withdrawn window by sending -a _NET_WM_DESKTOP client message to the root window (window is the respective -window, type _NET_WM_DESKTOP, format 32, l[0]=<desktop>) +a _NET_WM_DESKTOP client message to the root window: + The Window Manager MUST keep this property updated on all windows. @@ -571,6 +626,9 @@ If set, this property MUST contain the process ID of the client owning this window. This MAY be used by the Window Manager to kill windows which do not respond to the _NET_WM_PING protocol. + +See also the implementation notes on killing hung processes. + _NET_WM_HANDLED_ICONS + +See also the implementation notes on killing hung processes. + @@ -691,5 +752,37 @@ cause the window's window manager frame window to end up at (X, Y). The authors of this specification acknowledge that there is no standard method to allow the Window Manager to manage windows that a 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 the next revision of this specification. + + 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(STRING) to attempt to kill a process. + + + + Contributors + + Sasha Vasko + Bradley T. Hughes + Dominik Vogt + Havoc Pennington + Jeff Raven + Jim Gettys + John Harper + Julian Adams + Matthias Ettrich + Micheal Rogers + Nathan Clemons + Navindra Umanee + Tim Janik + Tomi Ollila + Sam Lantinga + The Rasterman + Paul Warren + Owen Taylor + Marko Macek + Greg Badros + + +
-- cgit v1.2.3-54-g00ecf From 4be26015c190edd919a06d25a9ef54d89897cf57 Mon Sep 17 00:00:00 2001 From: jools Date: Wed, 23 Aug 2000 17:07:14 +0000 Subject: updated Window Movement section. mainly --- wm-spec/wm-spec.sgml | 117 +++++++++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 108 insertions(+), 9 deletions(-) diff --git a/wm-spec/wm-spec.sgml b/wm-spec/wm-spec.sgml index 172f14b..5faee31 100644 --- a/wm-spec/wm-spec.sgml +++ b/wm-spec/wm-spec.sgml @@ -10,7 +10,7 @@ Version -This spec is version 1.0pre1. +This spec is version 1.0pre2. @@ -42,6 +42,17 @@ explicitly modifies the ICCCM Window Managers and Clients MUST fulfil these modifications. + + Changes since 1.0pre1 + + +Removed implementation note concerning Gnome's (potential) file manager behaviour. + + +The Window Movement section of the implementation notes has been revised. + + + Changes since 1.9f @@ -703,9 +714,6 @@ 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). - -Several GNOME file manager developers have accepted this model - Implementing enhanced support for application transient windows @@ -738,13 +746,104 @@ unlikely to break anything, it seems reasonable to document it as standard. Window Movement -According to the ICCCM, applications should not see unnecessary differences -between running with or without a window manager. Therefore window movements -for already mapped windows, such as ones requested by XMoveWindow(Display, -Window, X, Y) have to move the window Window to the coordinates (X, Y) and not -cause the window's window manager frame window to end up at (X, Y). +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: + + +Window managers MUST honour the win_gravity field of WM_NORMAL_HINTS + for both MapRequest _and_ ConfigureRequest events [1] + + +Applications are free to change their win_gravity setting at any time + + +If application changes its gravity then Window manager should adjust the +reference point, so that client window will not move as the result. +For example if client's gravity was NorthWestGravity and reference point +was +at the top-left corner of the frame window, then after change of gravity to +the SouthEast reference point should be adjusted to point to the +lower-right +corner of the frame. + + +When generating synthetic ConfigureNotify events, the position given + MUST be the top-left corner of the client window in relation to the + origin of the root window (i.e., ignoring win_gravity) [2] + + +XMoveWindow( w, x, y) behaviour depends on the window gravity: + + +StaticGravity: + + + window's left top corner will be placed at (x,y) + + +NorthWestGravity: + + + window frame's left top corner will be placed at (x,y) + + +NorthEastGravity: + + + window frame's right top corner will be placed at (x,y) + + +SouthWestGravity: + + + window frame's left bottom corner will be placed at (x,y) + + + +SouthEastGravity: + + + window frame's right bottom corner will be placed at (x,y) + + + +CenterGravity: + + + window frame's center will be placed at (x,y) + + + +(x,y) will become a new "reference point" for the client window. + + +Implementation Note for Application developers: + + +When client window is resized - its reference point does not move. +So for example if window has SouthEastGravity and it is resized - +the bottom-right corner of its frame will not move but instead +top-left corner will be adjusted by the difference in size. + + +Implementation Note for WM developers : + + +when calculating reference point at the time of initial placement - +initial window's width should be taken into consideration, as if it +was the frame for this window. + + + +[1] ICCCM Version 2.0, §4.1.2.3 and §4.1.5 + + +[2] ICCCM Version 2.0, §4.2.3 + Window-in-Window MDI -- cgit v1.2.3-54-g00ecf From f48c55d70c41e886a831b177e676e5b843dfe5b5 Mon Sep 17 00:00:00 2001 From: hp Date: Sat, 26 Aug 2000 16:22:25 +0000 Subject: remove Navindra Umanee from contributors at his request --- wm-spec/wm-spec.sgml | 1 - 1 file changed, 1 deletion(-) diff --git a/wm-spec/wm-spec.sgml b/wm-spec/wm-spec.sgml index 5faee31..ce8433c 100644 --- a/wm-spec/wm-spec.sgml +++ b/wm-spec/wm-spec.sgml @@ -872,7 +872,6 @@ If processes fail to respond to the _NET_WM_PING protocol _NET_WM_PID may be use Matthias Ettrich Micheal Rogers Nathan Clemons - Navindra Umanee Tim Janik Tomi Ollila Sam Lantinga -- cgit v1.2.3-54-g00ecf From 1d56e3a34b51020d22f7de171b72582ba9b3ca5e Mon Sep 17 00:00:00 2001 From: jools Date: Tue, 3 Oct 2000 19:22:58 +0000 Subject: spelling, and bug fixes --- wm-spec/wm-spec.sgml | 145 ++++++++++++++++++++++++++++++++++++++++----------- 1 file changed, 114 insertions(+), 31 deletions(-) diff --git a/wm-spec/wm-spec.sgml b/wm-spec/wm-spec.sgml index ce8433c..97335a0 100644 --- a/wm-spec/wm-spec.sgml +++ b/wm-spec/wm-spec.sgml @@ -10,13 +10,13 @@ Version -This spec is version 1.0pre2. +This spec is version 1.0pre3. What is this spec? -This spec defines interactions between window managers, applications and the utilities that form part of a desktop environment. It builds on the ICCCM, which defines wm/client interactions at a lower level. It was born out of a need to replace the original Gnome WM specification, although this specification has been designed to be independent of any one desktop environment. +This spec defines interactions between window managers, applications and the utilities that form part of a desktop environment. It builds on the ICCCM [2], which defines wm/client interactions at a lower level. It was born out of a need to replace the original Gnome WM specification, although this specification has been designed to be independent of any one desktop environment. @@ -42,6 +42,39 @@ explicitly modifies the ICCCM Window Managers and Clients MUST fulfil these modifications. + + Changes since 1.0pre2 + + +_NET_SET_NUMBER_OF_DESKTOPS -> _NET_NUMBER_OF_DESKTOPS for consistency. + + +_NET_WM_VISIBLE_NAME_STRING -> _NET_WM_VISIBLE_NAME for consistency. + + +_NET_WM_STATE: added explanation of permitted extensions. Added explanation of +being set / not set. + + +Spellchecked, corrected various typos. + + +UTF8 -> UTF-8 for consistency. + + +added references to the ICCCM an UTF-8 (incomplete). + + +added data and event formats where missing. + + +clarified _NET_SUPPORTING_WM_CHECK. + + +fixed formatting of _NET_CLOSE_WINDOW message. + + + Changes since 1.0pre1 @@ -234,12 +267,12 @@ This property SHOULD be set and updated by the Window Manager to indicate the number of virtual desktops. -A Pager can request change in the desktops number by sending a _NET_SET_NUMBER_OF_DESKTOPS message to the root window: +A Pager can request change in the desktops number by sending a _NET_NUMBER_OF_DESKTOPS message to the root window: @@ -260,10 +293,18 @@ Array of two cardinals that defines the width and height of each desktop in pixels. This property SHOULD be set by the Window Manager. -A Pager can change the desktop geometry by sending a _NET_DESKTOP_GEOMETRY client -message to the root window - +A Pager can request a change in the desktop geometry by sending a _NET_DESKTOP_GEOMETRY client +message to the root window: + + + +The Window Manager MAY choose to ignore this message, in which case _NET_DESKTOP_GEOMETRY property will remain unchanged. @@ -278,11 +319,18 @@ desktops, this MUST always be set to (0,0). A Pager can change the viewport for the current desktop by sending a -_NET_DESKTOP_VIEWPORT client message to the root window - +_NET_DESKTOP_VIEWPORT client message to the root window: + + +The Window Manager MAY choose to ignore this message, in which case _NET_DESKTOP_VIEWPORT property will remain unchanged. + _NET_CURRENT_DESKTOP , CARDINAL[1]/32 @@ -300,11 +348,10 @@ _NET_CURRENT_DESKTOP ]]> _NET_DESKTOP_NAMES -The names of all virtual desktops in UTF8 encoding. This property MAY be -changed by a Pager or the Window Mangaer at any time. +The names of all virtual desktops. This is a NULL spearated list of strings in UTF-8 [1] encoding with an additional NULL at the end of the list. This property MAY be changed by a Pager or the Window Manager at any time. _NET_ACTIVE_WINDOW - This property MUST be set by WM upon calculating the work area for each desktop (the first quadruple = desktop 1). Contains the left, right, top, bottom co-ordinates for each desktop. Work area SHOULD be used by desktop applications to place desktop icons apropriately. + This property MUST be set by WM upon calculating the work area for each desktop (the first quadruple = desktop 1). Contains the left, right, top, bottom co-ordinates for each desktop. Work area SHOULD be used by desktop applications to place desktop icons appropriately. The window manager SHOULD calculate this space by taking the current page minus space occupied by dock and panel windows, as indicated by the _NET_WM_STRUT property set on client windows. @@ -342,10 +389,19 @@ _NET_WORKAREA, CARDINAL[][4]/32 _NET_SUPPORTING_WM_CHECK, XA_WINDOW/32 ]]> -The Window Manager MUST set this property on the root window to be the ID of a child window created by the WM, to indicate that a compliant WM is active. The child window MUST also have the _NET_SUPPORTING_WM_CHECK property set with the same value. The child window MUST also have the _NET_WM_NAME property set to the name of the Window Manager. +The Window Manager MUST set this property on the root window to be the ID of a + child window created by the WM, to indicate that a compliant WM is + active. The child window MUST also have the _NET_SUPPORTING_WM_CHECK + property set to the ID of the child window. The child window MUST also + have the _NET_WM_NAME property set to the name of the Window Manager. -Rationale: The child window is used to guard against stale properties being left on the root window by a crashed WM. +Rationale: The child window is used to distinguish an active window manager + from a stale _NET_SUPPORTING_WM_CHECK + property that happens to point to another window. If the + _NET_SUPPORTING_WM_CHECK window on the client window is missing + or not properly set, clients SHOULD assume that no conforming + window manager is present. @@ -365,7 +421,18 @@ The Window Manager MUST set this to a list of IDs for windows that are acting as _NET_CLOSE_WINDOW ]]> - Pagers wanting to close a window MUST send a _NET_CLOSE_WINDOW client message request to the root window (type _NET_ACTIVE_WINDOW, format 32, l[0]=0 /*may be used later*/, window should be set to the window to close). The Window Manager MUST then attempt to close the window specified. + Pagers wanting to close a window MUST send a _NET_CLOSE_WINDOW client + message request to the root window: + + + +The Window Manager MUST then attempt to close the window specified. Rationale: A window manager might be more clever than the usual method (send WM_DELETE message if the protocol is selected, XKillClient otherwise). It might introduce a timeout, for example. Instead of duplicating the code, the Window Manager can easily do the job. @@ -403,20 +470,20 @@ _NET_WM_MOVERESIZE Application Window Properties _NET_WM_NAME -The Client SHOULD set this to the title of the window in UTF8 encoding. If +The Client SHOULD set this to the title of the window in UTF-8 encoding. If set, the Window Manager should use this in preference to WM_NAME. - _NET_WM_VISIBLE_NAME_STRING + _NET_WM_VISIBLE_NAME -If the Window Manager displays a window name other than _NET_WM_NAME the Window Manager MUST set this to the title displayed in UTF8 encoding. +If the Window Manager displays a window name other than _NET_WM_NAME the Window Manager MUST set this to the title displayed in UTF-8 encoding. Rationale: For window managers that display a title different from the _NET_WM_NAME or WM_NAME of the window (i.e. xterm <1>, xterm <2>, ... is shown, but _NET_WM_NAME / WM_NAME is still xterm for each window). This property allows taskbars / pagers to display the same title as the window manager. @@ -513,7 +580,9 @@ be taken as this type. _NET_WM_STATE, ATOM[] ]]> -A list of hints describing the state window. The Window Manager SHOULD honor +A list of hints describing the state window. Atoms present in the list MUST be +considered set, atoms not present in the list MUST be considered not set. The +Window Manager SHOULD honor _NET_WM_STATE whenever a withdrawn window requests to be mapped. A Client wishing to change the state of a window MUST send a _NET_WM_STATE client message to the root window (see below). The Window Manager MUST keep this @@ -530,6 +599,12 @@ _NET_WM_STATE_MAXIMIZED_HORZ, ATOM _NET_WM_STATE_SHADED, ATOM _NET_WM_STATE_SKIP_TASKBAR, ATOM ]]> + +An implementation MAY add new atoms to this list. Implementations +without extensions MUST ignore any unknown atoms, effectively removing +them from the list. These extension atoms MUST NOT start with the prefix +_NET. + _NET_WM_STATE_MODAL indicates that this is a modal dialog box. The WM_TRANSIENT_FOR hint MUST be set to indicate which window the dialog is a @@ -566,7 +641,7 @@ _NET_WM_STATE_REMOVE 0 /* remove/unset property */ _NET_WM_STATE_ADD 1 /* add/set property */ _NET_WM_STATE_TOGGLE 2 /* toggle property */ ]]> - + See also the implementation notes on urgency and fixed size windows. _NET_WM_STRUT @@ -575,7 +650,7 @@ _NET_WM_STRUT, CARDINAL[4]/32 ]]> This property MUST be set by the Client if the window is to reserve space at -the edge of the screen. The property is a 4-tupel of cardinals, one for each +the edge of the screen. The property is a 4-tuple of cardinals, one for each border of the screen. The order of the borders is left, right, top, bottom. The client MAY change this property anytime, therefore the Window Manager MUST watch out for property notify events. @@ -740,7 +815,7 @@ unlikely to break anything, it seems reasonable to document it as standard. Pagers and Taskbars - This specification attempts to make reasonable provisions for WM independant pagers and taskbars. Window Managers that require / desire additional functionality beyond what can be acheived 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. + 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. @@ -857,8 +932,16 @@ was the frame for this window. 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(STRING) to attempt to kill a process. - - + + + References + [1] UTF-8 + +[2] David Rosenthal / Stuart W. Marks "Inter-Client Communication Conventions + Manual (Version 2.0)", X Consortium Standard, X Version 11, Release 6.3 + + + Contributors Sasha Vasko -- cgit v1.2.3-54-g00ecf From ca06c4688223736e7f09f0d03553c2a7931f9980 Mon Sep 17 00:00:00 2001 From: hp Date: Fri, 10 Nov 2000 03:21:08 +0000 Subject: Add fixes from Matthias Clasen --- wm-spec/wm-spec.sgml | 426 +++++++++++++++++++++++++++++++++++++++++++++------ 1 file changed, 378 insertions(+), 48 deletions(-) diff --git a/wm-spec/wm-spec.sgml b/wm-spec/wm-spec.sgml index 97335a0..7cc89fd 100644 --- a/wm-spec/wm-spec.sgml +++ b/wm-spec/wm-spec.sgml @@ -3,14 +3,14 @@
Extended Window Manager Hints -15 March 2000 +5 November 2000 Introduction Version -This spec is version 1.0pre3. +This spec is version 1.0pre5. @@ -42,6 +42,84 @@ explicitly modifies the ICCCM Window Managers and Clients MUST fulfil these modifications. + + Changes since 1.0pre4 + + +Clarified the interpretation of client-provided geometries on large desktops. + + +Added more explanation for _NET_DESKTOP_NAMES. + + +Added _NET_WM_ICON_NAME and _NET_WM_VISIBLE_ICON_NAME. + + +Tried to improve the wording of _NET_WM_STRUT explanation. + + +Changed _NET_WORKAREA to an array of viewport-relative geometries. + + +Updated list of dependent properties for _NET_NUMBER_OF_DESKTOPS +to include _NET_WORKAREA and _NET_DESKTOP_VIEWPORT. + + +Tidied formatting of all client messages. + + + + + Changes since 1.0pre3 + + +Added information about common non-ICCCM features. + + +Added explanation of sending messages to the root window. + + +Removed XA_ prefix from type names. + + +Clarified that mapping order refers to inital mapping +and specify the directions of both orders. + + +Clarified that desktops have a common size specified by _NET_DESKTOP_GEOMETRY. + + +Rewrote explanation of _NET_DESKTOP_VIEWPORT. + + +Tidied formatting of _NET_CURRENT_DESKTOP. + + +Replaced window handle by window ID. + + +Tidied formatting of _NET_WORKAREA. + + +Rewrote the motivation for _NET_VIRTUAL_ROOTS. + + +Added advice on Pointer grabs to _NET_WM_MOVERESIZE. + + +Fixed typos in _NET_WM_STATE. + + +Added _NET_WM_STATE_SKIP_PAGER. + + +Tidied formatting of _NET_WM_STRUT. + + +Tidied formatting of _NET_WM_ICON_GEOMETRY. + + + Changes since 1.0pre2 @@ -235,8 +313,206 @@ Added _NET_WM_STATE_SKIP_TASKBAR + +Non-ICCCM features +There is a number of window management features or behaviours which are +not specified in the ICCCM, but are commonly met in modern Window Managers and Desktop Environments. + +Additional States +The ICCCM allows Window Managers to implement additional window states, which will +appear to clients as substates of NormalState and IconicState. Two +commonly met examples are Maximized and Shaded. A Window Manager may implement these +as proper substates of NormalState and IconicState, or it may treat them +as independent flags, allowing e.g. a maximized window to be iconified +and to re-appear as maximized upon de-iconification. + +Maximization +Maximization is a very old feature of Window Managers. There was even a ZoomedState +in early ICCCM drafts. Maximizing a window should give it as much of the +screen area as possible (this may not be the full screen area, but only +a smaller 'workarea', since the Window Manager may have reserved certain areas for other +windows). A Window Manager is expected to remember the geometry of a maximized window +and restore it upon de-maximization. Modern Window Managers typically allow separate +horizontal and vertical maximization. +With the introduction of the Xinerama extension in X11 R6.4, maximization +has become more involved. Xinerama allows a screen to span multiple +monitors in a freely configurable geometry. In such a setting, maximizing +a window would ideally not grow it to fill the whole screen, but only the +monitor it is shown on. There are of course borderline cases for windows +crossing monitor boundaries, and 'real' maximization to the full screen may +sometimes be useful. + + +Shading +Some Desktop Environments offer shading (also known as rollup) as an alternative to +iconfication. A shaded window typically shows only the titlebar, the client +window is hidden, thus shading is not useful for windows which are not +decorated with a titlebar. + + + +Modality +The Window Manager_TRANSIENT_FOR hint of the ICCCM allows clients to specify that a +toplevel window may be closed before the client finishes. A typical example +of a transient window is a dialog. Some dialogs can be open for a long time, +while the user continues to work in the main window. Other dialogs have to be +closed before the user can continue to work in the main window. This property +is called modality. While clients can implement modal windows in an ICCCM +compliant way using the globally active input model, some Window Managers offer support +for handling modality. + + + +Large Desktops +The Window Manager may offer to arrange the managed windows on a desktop that is +larger than the root window. The screen functions as a viewport on this large +desktop. Different policies regarding the positioning of the viewport on the +desktop can be implemented: The Window Manager may only allow to change the viewport +position in increments of the screen size (paging) or it may allow arbitrary +positions (scrolling). +To fulfill the ICCCM principle that clients should behave the same +regardless wether a Window Manager is running or not, Window Managers which +implement large desktops must interpret all client-provided geometries with +respect to the current viewport. + +Implementation note +There are two options for implementing a large desktop: The first is to +keep the managed windows (or, if reparenting, their frames) as children +of the root window. Moving the viewport is achieved by moving all managed +windows in the opposite direction. +The second alternative is to reparent all managed windows to a dedicated +large window (somewhat inappropriately called a 'virtual root'). Moving +the viewport is then achieved by moving the virtual root in the opposite +direction. +Both alternatives are completely ICCCM compliant, although the second one +may be somewhat problematic for clients trying to figure out the Window Manager decorations +around their toplevel windows and for clients trying to draw background +images on the root window. + + + +Sticky windows +A Window Manager which implements a large desktop typically offers a way for the user +to make certain windows 'stick to the glass', i.e. these windows will stay +at the same position on the screen when the viewport is moved. + + +Virtual Desktops +Most X servers have only a single screen. The Window Manager may virtualize this +resource and offer multiple so-called 'virtual desktops', of which only one +can be shown on the screen at a time. There is some variation among the +features of virtual desktop implementations. There may be a fixed number +of desktops, or new ones may be created dynamically. The size of the desktops +may be fixed or variable. If the desktops are larger than the root window, +their viewports (see ) may be independent or forced to be at the same +position. +A Window Manager which implements virtual desktops generally offers a way for the user +to move clients between desktops. Clients may be allowed to occupy more than +one desktop simultaneously. + +Implementation note +There are at least two options for implementing virtual desktops. +The first is to use multiple virtual roots (see ) and change the current +desktop by manipulating the stacking order of the virtual roots. This is +completely ICCCM compliant, but has the issues outlined in +The second option is to keep all managed windows as children of the root +window and unmap the frames of those which are not on the current desktop. +This puts the clients in an undefined ICCCM state, since they are unviewable, +but not iconic. In practice, this seems to cause no problems and the ICCCM +compliant alternative to iconify all clients on non-current desktops (without +showing their icons) is clearly not acceptable. + + + +Pagers +A pager offers a different UI for window management tasks. It shows a +miniature view of the desktop(s) representing managed windows by small +rectangles and allows the user to initiate various Window Manager actions by manipulating +these representations. Typically offered actions are activation (see ), +moving, restacking, iconification, maximization and closing. On a large +desktop, the pager may offer a way to move the viewport. On virtual desktops, +the pager may offer ways to move windows between desktops and to change the +current desktop. + + +Taskbars +A taskbar offers another UI for window management tasks. It typically +represents client windows as a list of buttons labelled with the window +titles and possibly icons. Pressing a button initiates a Window Manager action on the +represented window, typical actions being activation and iconification. +In environments with a taskbar, icons are often considered inappropriate, +since the iconified windows are already represented in the taskbar. + + +Activation +In the X world, activating a window means to give it the input focus. +This may not be possible if the window is unmapped, because it is on a +different desktop. Thus, activating a window may involve additional steps +like moving it to the current desktop (or changing to the desktop the window +is on), deiconifying it or raising it. + + +Animated iconification +Some Window Managers display some form of animation when (de-)iconfying a window. +This may be a line drawing connecting the corners of the window with +the corners of the icon or the window may be opaquely moved and resized +on some trajectory joining the window location and the icon location. + + +Window-in-window MDI +Window-in-window MDI is a multiple document interface known from MS +Windows platforms. Programs employing it have a single top-level window +which contains a workspace which contains the subwindows for the open +documents. These subwindows are decorated with Window Manager frames and can be +manipulated within their parent window just like ordinary top-level +windows on the root window. + + +Scope of this spec +This spec tries to address the following issues: + +Allow clients to influence their initial state with respect +to maximization, shading, stickyness, desktop. +Improve the Window Managers ability to vary window +decorations by allowing clients to hint the Window Manager about the type +of their windows. +Enable pagers and taskbars to be implemented as separate +clients and allow them to work with any compliant Window Manager. + +This spec doesn't cover any of the following: + +Other IPC mechanisms like ICE or Corba. +Window Manager configuration. +Window Manager documentation. +Geometry between desktops. +Clients appearing on a proper subset of desktops. +Window-in-window MDI. + +The Window Manager is supposed to be in charge of window management +policy, so that there is consistent behaviour on the user's screen no matter +who wrote the clients. +The spec offers a lot of external control about Window Manager actions. +This is intended mainly to allow pagers, taskbars and similar Window Manager +UIs to be implemented as separate clients. "Ordinary" clients shouldn't use +these except maybe in response to a direct user request (i.e. setting a +config option to start maximized or specifying a -desk n cmdline +argument). + + Root Window Properties (+Related Messages) + +Whenever this spec speaks about sending a message to the root +window, it is understood that the client is supposed to create +a ClientMessage event with the specified contents and send it by using +a SendEvent request with the following arguments: + + _NET_SUPPORTED _NET_CLIENT_LIST -An array of all X Windows managed by the Window Manager. _NET_CLIENT_LIST has -mapping order. _NET_CLIENT_LIST_STACKING has stacking order. This property +These arrays contain all X Windows managed by the Window Manager. +_NET_CLIENT_LIST has initial mapping order, starting with the oldest window. +_NET_CLIENT_LIST_STACKING has bottom-to-top stacking order. These properties SHOULD be set and updated by the Window Manager. @@ -264,20 +541,19 @@ _NET_NUMBER_OF_DESKTOPS, CARDINAL/32 ]]> This property SHOULD be set and updated by the Window Manager to indicate the -number of virtual desktops. +number of virtual desktops. A Pager can request change in the desktops number by sending a _NET_NUMBER_OF_DESKTOPS message to the root window: -The Window Manager is free to honor or reject this request. If request is honored _NET_NUMBER_OF_DESKTOPS MUST be set to the new number of desktops and _NET_VIRTUAL_ROOTS MUST be set to store the new number of desktop virtual root window IDs. The _NET_DESKTOP_NAMES property MAY remain unchanged. +The Window Manager is free to honor or reject this request. If request is honored _NET_NUMBER_OF_DESKTOPS MUST be set to the new number of desktops, _NET_VIRTUAL_ROOTS MUST be set to store the new number of desktop virtual root window IDs and _NET_DESKTOP_VIEWPORT and _NET_WORKAREA must also be changed accordingly. The _NET_DESKTOP_NAMES property MAY remain unchanged. If the number of desktops is shrinking and _NET_CURRENT_DESKTOP is out of the new range of of available desktops, then this MUST must be set to the last available desktop from the new set. If number of desktops is shrinking then clients that are still present on desktops, that are out of the new range, MUST be moved to the very last desktop from the new set. For these _NET_WM_DESKTOP MUST be updated. @@ -286,11 +562,11 @@ If the number of desktops is shrinking and _NET_CURRENT_DESKTOP is out of the ne _NET_DESKTOP_GEOMETRY -Array of two cardinals that defines the width and height of each desktop in -pixels. This property SHOULD be set by the Window Manager. +Array of two cardinals that defines the common size of all desktops. +This property SHOULD be set by the Window Manager. A Pager can request a change in the desktop geometry by sending a _NET_DESKTOP_GEOMETRY client @@ -310,15 +586,15 @@ The Window Manager MAY choose to ignore this message, in which case _NET_DESKTOP _NET_DESKTOP_VIEWPORT -Array of two cardinals that define the top left corner of the current view in -pixel, for each desktop. For window managers that don't support paged -desktops, this MUST always be set to (0,0). +Array of pairs of cardinals that define the top left corner of each desktops +viewport. For window managers that don't support large desktops, this MUST +always be set to (0,0). -A Pager can change the viewport for the current desktop by sending a +A Pager can request to change the viewport for the current desktop by sending a _NET_DESKTOP_VIEWPORT client message to the root window: _NET_CURRENT_DESKTOP , CARDINAL[1]/32 +_NET_CURRENT_DESKTOP desktop, CARDINAL/32 ]]> -The index of the current desktop, starts with desktop 0. This MUST be set and -updated by the Window Manager If a Pager wants to switch to another virtual -desktop, it MUST send a _NET_CURRENT_DESKTOP client message to the root window: +The index of the current desktop. This is always an integer between 0 and +_NET_NUMBER_OF_DESKTOPS - 1. This MUST be set and updated by the Window +Manager If a Pager wants to switch to another virtual desktop, it MUST send +a _NET_CURRENT_DESKTOP client message to the root window: -The names of all virtual desktops. This is a NULL spearated list of strings in UTF-8 [1] encoding with an additional NULL at the end of the list. This property MAY be changed by a Pager or the Window Manager at any time. +The names of all virtual desktops. This is a list of NULL-terminated strings in UTF-8 [1] encoding. This property MAY be changed by a Pager or the Window Manager at any time. + +Note: The number of names could be different from _NET_NUMBER_OF_DESKTOPS. +If it is less than _NET_NUMBER_OF_DESKTOPS - then the desktops with high +numbers are unnamed. If it is larger than _NET_NUMBER_OF_DESKTOPS, then the +excess names outside of the _NET_NUMBER_OF_DESKTOPS are considered to be +reserved in case number of desktops is increased. + + +Rationale: The name is not a necessary attribute of a virtual desktop. Thus +the availability or unavailability of names has no impact on virtual desktop +functionality. Since names are set by users and users are likely to preset +names for a fixed number of desktops, it doesn't make sense to shrink or grow +this list when the number of available desktops changes. + _NET_ACTIVE_WINDOW -The window handle of the currently active window. This is a read-only property -set by the +The window ID of the currently active window or None if no window has the focus. +This is a read-only property set by the window manager. If a client (for example, a taskbar) wants to activate another window, it MUST send a _NET_ACTIVE_WINDOW client message to the root window: _NET_WORKAREA - This property MUST be set by WM upon calculating the work area for each desktop (the first quadruple = desktop 1). Contains the left, right, top, bottom co-ordinates for each desktop. Work area SHOULD be used by desktop applications to place desktop icons appropriately. +This property MUST be set by WM upon calculating the work area for +each desktop. Contains a geometry for each desktop. These geometries are +specified relative to the viewport on each desktop and specify an area that is +completely contained within the viewport. + Work area SHOULD be used by desktop applications to place desktop icons appropriately. The window manager SHOULD calculate this space by taking the current page minus space occupied by dock and panel windows, as indicated by the _NET_WM_STRUT property set on client windows. @@ -386,7 +681,7 @@ _NET_WORKAREA, CARDINAL[][4]/32 _NET_SUPPORTING_WM_CHECK The Window Manager MUST set this property on the root window to be the ID of a @@ -407,10 +702,15 @@ Rationale: The child window is used to distinguish an active window manager _NET_VIRTUAL_ROOTS -The Window Manager MUST set this to a list of IDs for windows that are acting as virtual root windows. To implement virtual desktops, some window managers reparent client windows to a child of the root window. The property is present so that Pagers can determine which windows to watch for substructure notifies. +To implement virtual desktops, some window managers reparent client windows to +a child of the root window. Window managers using this technique MUST set +this property to a list of IDs for windows that are acting as virtual root +windows. This property allows background setting programs to work with +virtual roots and allows clients to figure out the WM frame windows of their +windows. @@ -440,7 +740,7 @@ The Window Manager MUST then attempt to close the window specified. _NET_WM_MOVERESIZE + + The client MUST release all grabs on Pointer events, prior to sending such message. + @@ -490,6 +793,27 @@ Rationale: For window managers that display a title different from the _NET_WM_N + _NET_WM_ICON_NAME + + +The Client SHOULD set this to the title of the icon for this window in UTF-8 +encoding. If set, the Window Manager should use this in preference to +WM_ICON_NAME. + + + + _NET_WM_VISIBLE_ICON_NAME + + +If the Window Manager displays an icon name other than _NET_WM_ICON_NAME +the Window Manager MUST set this to the title displayed in UTF-8 encoding. + + + _NET_WM_DESKTOP , CARDINAL/32 @@ -513,7 +837,7 @@ _NET_WM_DESKTOP window = the respective client window message_type = _NET_WM_DESKTOP format = 32 - data.l[0] = desktop + data.l[0] = new_desktop ]]> The Window Manager MUST keep this property updated on all windows. @@ -580,7 +904,7 @@ be taken as this type. _NET_WM_STATE, ATOM[] ]]> -A list of hints describing the state window. Atoms present in the list MUST be +A list of hints describing the window state. Atoms present in the list MUST be considered set, atoms not present in the list MUST be considered not set. The Window Manager SHOULD honor _NET_WM_STATE whenever a withdrawn window requests to be mapped. A Client @@ -598,6 +922,7 @@ _NET_WM_STATE_MAXIMIZED_VERT, ATOM _NET_WM_STATE_MAXIMIZED_HORZ, ATOM _NET_WM_STATE_SHADED, ATOM _NET_WM_STATE_SKIP_TASKBAR, ATOM +_NET_WM_STATE_SKIP_PAGER, ATOM ]]> An implementation MAY add new atoms to this list. Implementations @@ -623,10 +948,14 @@ _NET_WM_STATE_MAXIMIZED_{VERT,HORZ} indicates that the window is _NET_WM_STATE_SHADED indicates that the window is shaded. -_NET_WM_SKIP_TASKBAR indicates that a window should not be included on a +_NET_WM_SKIP_TASKBAR indicates that the window should not be included on a taskbar. +_NET_WM_SKIP_PAGER indicates that the window should not be included on a +pager. + + To change the state of a mapped window, a Client MUST send a _NET_WM_STATE client message to the root window (window is the respective window, type _NET_WM_STATE, format 32, l[0]=<the action, as listed below>, @@ -646,12 +975,13 @@ _NET_WM_STATE_TOGGLE 2 /* toggle property */ _NET_WM_STRUT This property MUST be set by the Client if the window is to reserve space at -the edge of the screen. The property is a 4-tuple of cardinals, one for each -border of the screen. The order of the borders is left, right, top, bottom. +the edge of the screen. The property contains a 4 cardinals specifying the +width of the reserved area at each border of the screen. +The order of the borders is left, right, top, bottom. The client MAY change this property anytime, therefore the Window Manager MUST watch out for property notify events. @@ -673,12 +1003,11 @@ SHOULD only set one strut. _NET_WM_ICON_GEOMETRY -An array of x,y,w,h of type CARDINAL, format 32. This optional property MAY -be set by standalone tools like a taskbar or an iconbox. It specifies the -geometry of a possible icon in case the window is iconified. +This optional property MAY be set by standalone tools like a taskbar or an +iconbox. It specifies the geometry of a possible icon in case the window is iconified. Rationale: This makes it possible for a window manager to display a nice @@ -746,11 +1075,11 @@ as follows: +window = the respective client window message_type = WM_PROTOCOLS format = 32 data.l[0] = _NET_WM_PING -data.l[1] = +data.l[1] = timestamp ]]> A participating Client receiving this message MUST send it back to the root @@ -914,10 +1243,10 @@ was the frame for this window. -[1] ICCCM Version 2.0, §4.1.2.3 and §4.1.5 +[1] ICCCM Version 2.0, §4.1.2.3 and §4.1.5 -[2] ICCCM Version 2.0, §4.2.3 +[2] ICCCM Version 2.0, §4.2.3 @@ -963,7 +1292,8 @@ If processes fail to respond to the _NET_WM_PING protocol _NET_WM_PID may be use Owen Taylor Marko Macek Greg Badros - + Matthias Clasen +
-- cgit v1.2.3-54-g00ecf From b58352845cebc1d3b5754215a03ed047d1b28b11 Mon Sep 17 00:00:00 2001 From: jools Date: Wed, 22 Nov 2000 21:40:56 +0000 Subject: update version: David's comments (thanks David!) Sasha revisions to the window gravity stuff (unless somebody finds that it's incorrect) UTF-8 = RFC 2279 reference X style copyright - copied from ICCCM Revision -> 1.0 ! (objections ?) --- wm-spec/wm-spec.sgml | 1039 ++++++++++++++++++++++++++++---------------------- 1 file changed, 592 insertions(+), 447 deletions(-) diff --git a/wm-spec/wm-spec.sgml b/wm-spec/wm-spec.sgml index 7cc89fd..cc67e3a 100644 --- a/wm-spec/wm-spec.sgml +++ b/wm-spec/wm-spec.sgml @@ -10,7 +10,7 @@ Version -This spec is version 1.0pre5. +This spec is version 1.0. @@ -42,276 +42,6 @@ explicitly modifies the ICCCM Window Managers and Clients MUST fulfil these modifications. - - Changes since 1.0pre4 - - -Clarified the interpretation of client-provided geometries on large desktops. - - -Added more explanation for _NET_DESKTOP_NAMES. - - -Added _NET_WM_ICON_NAME and _NET_WM_VISIBLE_ICON_NAME. - - -Tried to improve the wording of _NET_WM_STRUT explanation. - - -Changed _NET_WORKAREA to an array of viewport-relative geometries. - - -Updated list of dependent properties for _NET_NUMBER_OF_DESKTOPS -to include _NET_WORKAREA and _NET_DESKTOP_VIEWPORT. - - -Tidied formatting of all client messages. - - - - - Changes since 1.0pre3 - - -Added information about common non-ICCCM features. - - -Added explanation of sending messages to the root window. - - -Removed XA_ prefix from type names. - - -Clarified that mapping order refers to inital mapping -and specify the directions of both orders. - - -Clarified that desktops have a common size specified by _NET_DESKTOP_GEOMETRY. - - -Rewrote explanation of _NET_DESKTOP_VIEWPORT. - - -Tidied formatting of _NET_CURRENT_DESKTOP. - - -Replaced window handle by window ID. - - -Tidied formatting of _NET_WORKAREA. - - -Rewrote the motivation for _NET_VIRTUAL_ROOTS. - - -Added advice on Pointer grabs to _NET_WM_MOVERESIZE. - - -Fixed typos in _NET_WM_STATE. - - -Added _NET_WM_STATE_SKIP_PAGER. - - -Tidied formatting of _NET_WM_STRUT. - - -Tidied formatting of _NET_WM_ICON_GEOMETRY. - - - - - Changes since 1.0pre2 - - -_NET_SET_NUMBER_OF_DESKTOPS -> _NET_NUMBER_OF_DESKTOPS for consistency. - - -_NET_WM_VISIBLE_NAME_STRING -> _NET_WM_VISIBLE_NAME for consistency. - - -_NET_WM_STATE: added explanation of permitted extensions. Added explanation of -being set / not set. - - -Spellchecked, corrected various typos. - - -UTF8 -> UTF-8 for consistency. - - -added references to the ICCCM an UTF-8 (incomplete). - - -added data and event formats where missing. - - -clarified _NET_SUPPORTING_WM_CHECK. - - -fixed formatting of _NET_CLOSE_WINDOW message. - - - - - Changes since 1.0pre1 - - -Removed implementation note concerning Gnome's (potential) file manager behaviour. - - -The Window Movement section of the implementation notes has been revised. - - - - - Changes since 1.9f - - -Revised revision number for first accepted release 1.9XX -> 1.0preXX. - - -Prerequisites for adoption of this specification added. - - -Tidied formatting of _NET_CURRENT_DESKTOP for consistency. - - -Tidied formatting of _NET_ACTIVE_WINDOW for consistency. Removed doubled text. - - -Tidied formatting of _NET_WM_DESKTOP for consistency. - - -Killing Hung Processes implementation note added. _NET_WM_PID and _NET_WM_PING now link to this. - - -Clarified x_root and y_root meaning for _NET_WM_MOVERESIZE. - - -Added contributor list. - - - - - Changes since 1.9e - - -Added _NET_WM_VISIBLE_NAME_STRING - - -Removed ambiguity from _NET_NUMBER_OF_DESKTOPS and _NET_DESKTOP_NAMES in combination. - - -Set _NET_WM_MOVERESIZE format to 32 for consistency. - - -Removed _NET_PROPERTIES. - - -Removed comment from _NET_WM_MOVERESIZE. - - - - - Changes since 1.9d - - -Added _NET_VIRTUAL_ROOTS - - -Added note about ICCCM compliant window moves. - - -Added _NET_WM_HANDLED_ICONS - - -Added _NET_SUPPORTING_WM_CHECK - - -Removed degrees of activation - - - - - Changes since 1.9c - - - -Removed packaging of hints into 2 X properties. Jim Gettys points out that the -performance gains of fewer round trips can be better achieved using Xlib -routines. - - - - -Clarified that _NET_DESKTOP_VIEWPORT is in pixels - - - - -_NET_DESKTOP_VIEWPORT is now an array, one for each desktop, to allow for -different active viewports on different desktops - - - - -_NET_WM_STRUT now only applies on desktops on which the client is visible - - - - -Introduced RFC 2119 language, and attempted to clarify the roles of the Window -Manager, Pagers and Applications - - - - -Added _NET_WM_NAME - - - - -_NET_DESKTOP_NAMES now in UTF8 - - - - -Desktops now start from 0 - - - - -Added _NET_WM_PID - - - - -Added _NET_WM_PING protocol - - - - -Added _NET_WM_STATE_SKIP_TASKBAR - - - - - - - Changes since 1.9b - - Removed _NET_NUMBER_OF_DESKTOPS client message, as it overlaps unnecessarily with _NET_{INSERT/DELETE}_DESKTOP. - - Replaced _NET_WM_LAYER and _NET_WM_HINTS with _NET_WM_WINDOW_TYPE functional hint. - Changed _NET_WM_STATE to a list of atoms, for extensibility. - Expanded description of _NET_WORKAREA and _NET_WM_STRUT. - Removed _NET_WM_SIZEMOVE_NOTIFY protocol. - Added degrees of activation to _NET_ACTIVE_WINDOW client message - Added _NET_WM_ICON - My comments are in [[ ]]. Comments from Marko's draft are in [[MM: ]] - - Non-ICCCM features @@ -1106,194 +836,609 @@ 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. - - - File Manager desktop + + + 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). + + + + 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. + + + + 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. + + + + 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. + + + + 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. + + + + 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: + + + +Window managers MUST honour the win_gravity field of WM_NORMAL_HINTS + for both MapRequest _and_ ConfigureRequest events [1] + + +Applications are free to change their win_gravity setting at any time + + +If application changes its gravity then Window manager should adjust the +reference point, so that client window will not move as the result. +For example if client's gravity was NorthWestGravity and reference point +was +at the top-left corner of the frame window, then after change of gravity to +the SouthEast reference point should be adjusted to point to the +lower-right +corner of the frame. + + +When generating synthetic ConfigureNotify events, the position given + MUST be the top-left corner of the client window in relation to the + origin of the root window (i.e., ignoring win_gravity) [2] + + +XMoveWindow(w,x,y) behaviour depends on the window gravity. Upon receiving a +request from client application the Window Manager calculates a new reference +point, based on the client window's own size, border width and gravity. For given client +window dimentions (width, height) and border width (bw), the reference point will be +placed at: + + + + + + Gravity: + ref_x: + ref_y: + + + StaticGravity + x + y + + + NorthWestGravity + x-bw + y-bw + + + NorthGravity + x+(width/2) + y-bw + + + NorthEastGravity + x+width+bw + y-bw + + + EastGravity + x+width+bw + y+(height/2) + + + SouthEastGravity + x+width+bw + y+height+bw + + + SouthGravity + x+(width/2) + y+height+bw + + + SouthWestGravity + x-bw + y+height+bw + + + WestGravity + x-bw + y+(height/2) + + + CenterGravity + x+(width/2) + y+(height/2) + + + + + + +The Window manager will use the reference point as calculated above, +until next XMoveWindow request. The Window Manager will place frame decorations +in the following position, based on the window gravity : + + +StaticGravity: + + +window's left top corner will be placed at (ref_x,ref_y) + + +NorthWestGravity: + + +window frame's left top corner will be placed at (ref_x,ref_y) + + +NorthGravity: + + +window frame's top side's center will be placed at (ref_x,ref_y) + + +NorthEastGravity: + + +window frame's right top corner will be placed at (ref_x,ref_y) + + +EastGravity: + + +window frame's right side's center will be placed at (ref_x,ref_y) + + +SouthWestGravity: + + +window frame's left bottom corner will be placed at (ref_x,ref_y) + + +SouthGravity: + + +window frame's bottom side's center will be placed at (ref_x,ref_y) + + +SouthEastGravity: + + +window frame's right bottom corner will be placed at (ref_x,ref_y) + + +WestGravity: + + +window frame's left side's center will be placed at (ref_x,ref_y) + + +CenterGravity: + + +window frame's center will be placed at (ref_x,ref_y) + + + +Implementation Note for Application developers: + -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). +When client window is resized - its reference point does not move. +So for example if window has SouthEastGravity and it is resized - +the bottom-right corner of its frame will not move but instead +top-left corner will be adjusted by the difference in size. + + +Implementation Note for WM developers : + +when calculating reference point at the time of initial placement - +initial window's width should be taken into consideration, as if it +was the frame for this window. + + + +[1] ICCCM Version 2.0, §4.1.2.3 and §4.1.5 + + +[2] ICCCM Version 2.0, §4.2.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. - + 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 the next revision of this specification. + - - Urgency + + Killing Hung Processes - 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. +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(STRING) to attempt to kill a process. - - 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. - + + + References + +[1] F. Yergeau,"UTF-8, a transformation format of ISO 10646", RFC 2279 + + +[2] David Rosenthal / Stuart W. Marks "Inter-Client Communication Conventions + Manual (Version 2.0)", X Consortium Standard, X Version 11, Release 6.3 + + + + Copyright + +Copyright (C) 2000 See Contributors List + + +Permission is hereby granted, free of charge, to any person +obtaining a copy of this software and associated documentation +files (the "Software"), to deal in the Software without +restriction, including without limitation the rights to use, +copy, modify, merge, publish, distribute, sublicense, and/or +sell copies of the Software, and to permit persons to whom +the Software is furnished to do so, subject to the following +conditions: + + +The above copyright notice and this permission notice shall +be included in all copies or substantial portions of the +Software. + + +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY +KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE +WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE +AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS +BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, +WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING +FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE +OR OTHER DEALINGS IN THE SOFTWARE. + + + + Contributors + + Sasha Vasko + Bradley T. Hughes + Dominik Vogt + Havoc Pennington + Jeff Raven + Jim Gettys + John Harper + Julian Adams + Matthias Ettrich + Micheal Rogers + Nathan Clemons + Tim Janik + Tomi Ollila + Sam Lantinga + The Rasterman + Paul Warren + Owen Taylor + Marko Macek + Greg Badros + Matthias Clasen + David Rosenthal + + + + Change history + + Changes since 1.0pre5 + + +Change history moved to end. + + +UTF-8 Reference updated. + + +Window Gravity information updated. + + +Copyright Added. + + +Minor typo corrections. + + + + + Changes since 1.0pre4 + + +Clarified the interpretation of client-provided geometries on large desktops. + + +Added more explanation for _NET_DESKTOP_NAMES. + + +Added _NET_WM_ICON_NAME and _NET_WM_VISIBLE_ICON_NAME. + + +Tried to improve the wording of _NET_WM_STRUT explanation. + + +Changed _NET_WORKAREA to an array of viewport-relative geometries. + + +Updated list of dependent properties for _NET_NUMBER_OF_DESKTOPS +to include _NET_WORKAREA and _NET_DESKTOP_VIEWPORT. + + +Tidied formatting of all client messages. + + - 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. - + Changes since 1.0pre3 + + +Added information about common non-ICCCM features. + + +Added explanation of sending messages to the root window. + + +Removed XA_ prefix from type names. + + +Clarified that mapping order refers to inital mapping +and specify the directions of both orders. + + +Clarified that desktops have a common size specified by _NET_DESKTOP_GEOMETRY. + + +Rewrote explanation of _NET_DESKTOP_VIEWPORT. + + +Tidied formatting of _NET_CURRENT_DESKTOP. + + +Replaced window handle by window ID. + + +Tidied formatting of _NET_WORKAREA. + + +Rewrote the motivation for _NET_VIRTUAL_ROOTS. + + +Added advice on Pointer grabs to _NET_WM_MOVERESIZE. + + +Fixed typos in _NET_WM_STATE. + + +Added _NET_WM_STATE_SKIP_PAGER. + + +Tidied formatting of _NET_WM_STRUT. + + +Tidied formatting of _NET_WM_ICON_GEOMETRY. + + + + + Changes since 1.0pre2 + + +_NET_SET_NUMBER_OF_DESKTOPS -> _NET_NUMBER_OF_DESKTOPS for consistency. + + +_NET_WM_VISIBLE_NAME_STRING -> _NET_WM_VISIBLE_NAME for consistency. + + +_NET_WM_STATE: added explanation of permitted extensions. Added explanation of +being set / not set. + + +Spellchecked, corrected various typos. + + +UTF8 -> UTF-8 for consistency. + + +added references to the ICCCM an UTF-8 (incomplete). + + +added data and event formats where missing. + + +clarified _NET_SUPPORTING_WM_CHECK. + + +fixed formatting of _NET_CLOSE_WINDOW message. + + + + + Changes since 1.0pre1 + + +Removed implementation note concerning Gnome's (potential) file manager behaviour. + + +The Window Movement section of the implementation notes has been revised. + + + + + Changes since 1.9f + + +Revised revision number for first accepted release 1.9XX -> 1.0preXX. + + +Prerequisites for adoption of this specification added. + + +Tidied formatting of _NET_CURRENT_DESKTOP for consistency. + + +Tidied formatting of _NET_ACTIVE_WINDOW for consistency. Removed doubled text. + + +Tidied formatting of _NET_WM_DESKTOP for consistency. + + +Killing Hung Processes implementation note added. _NET_WM_PID and _NET_WM_PING now link to this. + + +Clarified x_root and y_root meaning for _NET_WM_MOVERESIZE. + + +Added contributor list. + + + + + Changes since 1.9e + + +Added _NET_WM_VISIBLE_NAME_STRING + + +Removed ambiguity from _NET_NUMBER_OF_DESKTOPS and _NET_DESKTOP_NAMES in combination. + + +Set _NET_WM_MOVERESIZE format to 32 for consistency. + + +Removed _NET_PROPERTIES. + + +Removed comment from _NET_WM_MOVERESIZE. + + + + + Changes since 1.9d + + +Added _NET_VIRTUAL_ROOTS + + +Added note about ICCCM compliant window moves. + + +Added _NET_WM_HANDLED_ICONS + + +Added _NET_SUPPORTING_WM_CHECK + + +Removed degrees of activation + + + + + Changes since 1.9c + + + +Removed packaging of hints into 2 X properties. Jim Gettys points out that the +performance gains of fewer round trips can be better achieved using Xlib +routines. + + + + +Clarified that _NET_DESKTOP_VIEWPORT is in pixels + + + + +_NET_DESKTOP_VIEWPORT is now an array, one for each desktop, to allow for +different active viewports on different desktops + + + + +_NET_WM_STRUT now only applies on desktops on which the client is visible + + + + +Introduced RFC 2119 language, and attempted to clarify the roles of the Window +Manager, Pagers and Applications + + + + +Added _NET_WM_NAME + + + + +_NET_DESKTOP_NAMES now in UTF8 + + + + +Desktops now start from 0 + + + + +Added _NET_WM_PID + + + + +Added _NET_WM_PING protocol + + + + +Added _NET_WM_STATE_SKIP_TASKBAR + + + + - 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: - + Changes since 1.9b - -Window managers MUST honour the win_gravity field of WM_NORMAL_HINTS - for both MapRequest _and_ ConfigureRequest events [1] - - -Applications are free to change their win_gravity setting at any time - - -If application changes its gravity then Window manager should adjust the -reference point, so that client window will not move as the result. -For example if client's gravity was NorthWestGravity and reference point -was -at the top-left corner of the frame window, then after change of gravity to -the SouthEast reference point should be adjusted to point to the -lower-right -corner of the frame. - - -When generating synthetic ConfigureNotify events, the position given - MUST be the top-left corner of the client window in relation to the - origin of the root window (i.e., ignoring win_gravity) [2] - - -XMoveWindow( w, x, y) behaviour depends on the window gravity: - - -StaticGravity: - - - window's left top corner will be placed at (x,y) - - -NorthWestGravity: - - - window frame's left top corner will be placed at (x,y) - - -NorthEastGravity: - - - window frame's right top corner will be placed at (x,y) - - - -SouthWestGravity: - - - window frame's left bottom corner will be placed at (x,y) - - - -SouthEastGravity: - - - window frame's right bottom corner will be placed at (x,y) - - - -CenterGravity: - - - window frame's center will be placed at (x,y) - - - -(x,y) will become a new "reference point" for the client window. - - -Implementation Note for Application developers: - - -When client window is resized - its reference point does not move. -So for example if window has SouthEastGravity and it is resized - -the bottom-right corner of its frame will not move but instead -top-left corner will be adjusted by the difference in size. - - -Implementation Note for WM developers : - - -when calculating reference point at the time of initial placement - -initial window's width should be taken into consideration, as if it -was the frame for this window. - + Removed _NET_NUMBER_OF_DESKTOPS client message, as it overlaps unnecessarily with _NET_{INSERT/DELETE}_DESKTOP. + + Replaced _NET_WM_LAYER and _NET_WM_HINTS with _NET_WM_WINDOW_TYPE functional hint. + Changed _NET_WM_STATE to a list of atoms, for extensibility. + Expanded description of _NET_WORKAREA and _NET_WM_STRUT. + Removed _NET_WM_SIZEMOVE_NOTIFY protocol. + Added degrees of activation to _NET_ACTIVE_WINDOW client message + Added _NET_WM_ICON + My comments are in [[ ]]. Comments from Marko's draft are in [[MM: ]] - -[1] ICCCM Version 2.0, §4.1.2.3 and §4.1.5 - - -[2] ICCCM Version 2.0, §4.2.3 - - - - 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 a 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 the next revision of this specification. - - - - 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(STRING) to attempt to kill a process. - - - - - References - [1] UTF-8 - -[2] David Rosenthal / Stuart W. Marks "Inter-Client Communication Conventions - Manual (Version 2.0)", X Consortium Standard, X Version 11, Release 6.3 - - - - Contributors - - Sasha Vasko - Bradley T. Hughes - Dominik Vogt - Havoc Pennington - Jeff Raven - Jim Gettys - John Harper - Julian Adams - Matthias Ettrich - Micheal Rogers - Nathan Clemons - Tim Janik - Tomi Ollila - Sam Lantinga - The Rasterman - Paul Warren - Owen Taylor - Marko Macek - Greg Badros - Matthias Clasen - - - + +
-- cgit v1.2.3-54-g00ecf From 3a5a13a1fe2b1a2851e0c3d6050b1535875cc9fd Mon Sep 17 00:00:00 2001 From: hp Date: Sun, 11 Mar 2001 20:24:39 +0000 Subject: some updates --- wm-spec/wm-spec.sgml | 40 +++++++++++++++++++++++++++------------- 1 file changed, 27 insertions(+), 13 deletions(-) diff --git a/wm-spec/wm-spec.sgml b/wm-spec/wm-spec.sgml index cc67e3a..a6fe26f 100644 --- a/wm-spec/wm-spec.sgml +++ b/wm-spec/wm-spec.sgml @@ -1,22 +1,36 @@ -
- + + + + X Desktop Group + + Extended Window Manager Hints -5 November 2000 - +10 March 2001 + Introduction Version -This spec is version 1.0. +This is version 1.1 of the Extended Window Manager Hints (EWMH) spec, +updated 10 March 2001. What is this spec? -This spec defines interactions between window managers, applications and the utilities that form part of a desktop environment. It builds on the ICCCM [2], which defines wm/client interactions at a lower level. It was born out of a need to replace the original Gnome WM specification, although this specification has been designed to be independent of any one desktop environment. +This spec defines interactions between window managers, applications, +and the utilities that form part of a desktop environment. It builds +on the ICCCM [2], which defines WM (window manager) interactions at a +lower level. The ICCCM does not provide ways to implement many +features that modern desktop users expect. The GNOME and KDE desktop +projects originally developed their own extensions to the ICCCM to +support these features; this spec replaces those custom extensions +with a standardized set of ICCCM additions that any desktop +environment can adopt. @@ -82,7 +96,7 @@ decorated with a titlebar. Modality -The Window Manager_TRANSIENT_FOR hint of the ICCCM allows clients to specify that a +The Window Manager _TRANSIENT_FOR hint of the ICCCM allows clients to specify that a toplevel window may be closed before the client finishes. A typical example of a transient window is a dialog. Some dialogs can be open for a long time, while the user continues to work in the main window. Other dialogs have to be @@ -183,7 +197,7 @@ is on), deiconifying it or raising it. Animated iconification -Some Window Managers display some form of animation when (de-)iconfying a window. +Some Window Managers display some form of animation when (de-)iconifying a window. This may be a line drawing connecting the corners of the window with the corners of the icon or the window may be opaquely moved and resized on some trajectory joining the window location and the icon location. @@ -286,7 +300,7 @@ _NET_NUMBER_OF_DESKTOPS The Window Manager is free to honor or reject this request. If request is honored _NET_NUMBER_OF_DESKTOPS MUST be set to the new number of desktops, _NET_VIRTUAL_ROOTS MUST be set to store the new number of desktop virtual root window IDs and _NET_DESKTOP_VIEWPORT and _NET_WORKAREA must also be changed accordingly. The _NET_DESKTOP_NAMES property MAY remain unchanged. -If the number of desktops is shrinking and _NET_CURRENT_DESKTOP is out of the new range of of available desktops, then this MUST must be set to the last available desktop from the new set. If number of desktops is shrinking then clients that are still present on desktops, that are out of the new range, MUST be moved to the very last desktop from the new set. For these _NET_WM_DESKTOP MUST be updated. +If the number of desktops is shrinking and _NET_CURRENT_DESKTOP is out of the new range of available desktops, then this MUST be set to the last available desktop from the new set. If number of desktops is shrinking then clients that are still present on desktops, that are out of the new range, MUST be moved to the very last desktop from the new set. For these _NET_WM_DESKTOP MUST be updated. @@ -577,7 +591,7 @@ _NET_WM_DESKTOP _NET_WM_WINDOW_TYPE, ATOM[]/32 ]]> -This MUST be set by the Client before mapping, to a list of atoms indicating +This SHOULD be set by the Client before mapping, to a list of atoms indicating the functional type of the window. This property SHOULD be used by the window manager in determining the decoration, stacking position and other behaviour of the window. The Client SHOULD specify window types in order of preference @@ -757,7 +771,7 @@ icons to an appropriate size. This is an array of 32bit packed CARDINAL ARGB with high byte being A, low -byte being B. First two bytes are width, height. Data is in rows, left to +byte being B. First two cardinals are width, height. Data is in rows, left to right and top to bottom. @@ -1062,10 +1076,10 @@ was the frame for this window. -[1] ICCCM Version 2.0, §4.1.2.3 and §4.1.5 +[1] ICCCM Version 2.0, §4.1.2.3 and §4.1.5 -[2] ICCCM Version 2.0, §4.2.3 +[2] ICCCM Version 2.0, §4.2.3 -- cgit v1.2.3-54-g00ecf From e3dc3ddc0c9f5ac3dfcd24c0592e41f3db702079 Mon Sep 17 00:00:00 2001 From: jools Date: Sun, 22 Apr 2001 10:14:49 +0000 Subject: added clarification to _NET_SUPPORTED --- wm-spec/wm-spec.sgml | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/wm-spec/wm-spec.sgml b/wm-spec/wm-spec.sgml index a6fe26f..f59eac7 100644 --- a/wm-spec/wm-spec.sgml +++ b/wm-spec/wm-spec.sgml @@ -263,8 +263,10 @@ _NET_SUPPORTED, ATOM[]/32 ]]> This property MUST be set by the Window Manager to indicate which hints it -supports. This assumes that backwards incompatible changes will not be made -to the hints (without being renamed). +supports. For example: considering _NET_WM_STATE +both this atom and all supported states e.g. _NET_WM_STATE_MODAL, +_NET_WM_STATE_STICKY, would be listed. This assumes that backwards +incompatible changes will not be made to the hints (without being renamed). _NET_CLIENT_LIST Date: Wed, 9 May 2001 02:55:08 +0000 Subject: added change list for 1.1 -> final 1.1 version ? --- wm-spec/wm-spec.sgml | 26 ++++++++++++++++++++++++++ 1 file changed, 26 insertions(+) diff --git a/wm-spec/wm-spec.sgml b/wm-spec/wm-spec.sgml index f59eac7..aa52e4a 100644 --- a/wm-spec/wm-spec.sgml +++ b/wm-spec/wm-spec.sgml @@ -1166,6 +1166,32 @@ OR OTHER DEALINGS IN THE SOFTWARE. Change history + + Changes since 1.0 + + +Fix doctype, add author info, update data. + + +Change specification description wording to be more inclusive, and to reflect the joint nature of the specification. + + +Fix miscellaneous typographical, grammar and spelling errors. + + +Clarified _NET_SUPPORTED to include ALL atoms, not just the property names. + + +Various corrections to use of MUST and SHOULD. + + +Fix problem in _NET_WM_ICON where 'bytes' should have been 'cardinals' + + +Replaced ISO-8559-1 characters with entities. + + + Changes since 1.0pre5 -- cgit v1.2.3-54-g00ecf From e1ab9b7167c3d89c06a1da0811566aa8d6e38e38 Mon Sep 17 00:00:00 2001 From: hp Date: Tue, 28 Aug 2001 12:50:36 +0000 Subject: Add changes to clarify that you have to use the machine name with the PID hint --- wm-spec/wm-spec.sgml | 60 +++++++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 59 insertions(+), 1 deletion(-) diff --git a/wm-spec/wm-spec.sgml b/wm-spec/wm-spec.sgml index aa52e4a..1440d3f 100644 --- a/wm-spec/wm-spec.sgml +++ b/wm-spec/wm-spec.sgml @@ -788,6 +788,14 @@ window. This MAY be used by the Window Manager to kill windows which do not respond to the _NET_WM_PING protocol. +If _NET_WM_PID is set, the ICCCM-specified property WM_CLIENT_MACHINE +MUST also be set. While the ICCCM only requests that WM_CLIENT_MACHINE is set + to a string that forms the name of the machine running the client as +seen from the machine running the server conformance to this +specification requires that WM_CLIENT_MACHINE be set to the fully-qualified domain +name of the client's host. + + See also the implementation notes on killing hung processes. @@ -1093,7 +1101,46 @@ was the frame for this window. 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(STRING) to attempt to kill a process. +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: + + + = maxlen) len = maxlen - 1; + strncpy (buf, name.nodename, len); + buf[len] = '\0'; + + return len; +#endif +} +]]> @@ -1166,6 +1213,17 @@ OR OTHER DEALINGS IN THE SOFTWARE. Change history + + Changes since 1.1 + + + Changed WM_CLIENT_NAME(STRING) from suggested to required for _NET_WM_PID. + + + Specification and sample code for the content of WM_CLIENT_NAME(STRING). + + + Changes since 1.0 -- cgit v1.2.3-54-g00ecf From 03eb8fe8d7b0ad9be2aecb71085df97398d1512a Mon Sep 17 00:00:00 2001 From: hp Date: Tue, 28 Aug 2001 13:00:30 +0000 Subject: s/UTF-8_STRING/UTF8_STRING/ --- wm-spec/wm-spec.sgml | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/wm-spec/wm-spec.sgml b/wm-spec/wm-spec.sgml index 1440d3f..d396d01 100644 --- a/wm-spec/wm-spec.sgml +++ b/wm-spec/wm-spec.sgml @@ -371,7 +371,7 @@ _NET_CURRENT_DESKTOP ]]> _NET_DESKTOP_NAMES The names of all virtual desktops. This is a list of NULL-terminated strings in UTF-8 [1] encoding. This property MAY be changed by a Pager or the Window Manager at any time. @@ -519,7 +519,7 @@ _NET_WM_MOVERESIZE Application Window Properties _NET_WM_NAME The Client SHOULD set this to the title of the window in UTF-8 encoding. If @@ -529,7 +529,7 @@ set, the Window Manager should use this in preference to WM_NAME. _NET_WM_VISIBLE_NAME If the Window Manager displays a window name other than _NET_WM_NAME the Window Manager MUST set this to the title displayed in UTF-8 encoding. @@ -541,7 +541,7 @@ Rationale: For window managers that display a title different from the _NET_WM_N _NET_WM_ICON_NAME The Client SHOULD set this to the title of the icon for this window in UTF-8 @@ -552,7 +552,7 @@ WM_ICON_NAME. _NET_WM_VISIBLE_ICON_NAME If the Window Manager displays an icon name other than _NET_WM_ICON_NAME -- cgit v1.2.3-54-g00ecf From ef38bc5a69eef20bf347b1f464f43482ebd65f50 Mon Sep 17 00:00:00 2001 From: hp Date: Wed, 17 Oct 2001 12:43:02 +0000 Subject: add TYPE_UTILITY, TYPE_SPLASH, STATE_FULLSCREEN --- wm-spec/wm-spec.sgml | 38 +++++++++++++++++++++++++++++++++----- 1 file changed, 33 insertions(+), 5 deletions(-) diff --git a/wm-spec/wm-spec.sgml b/wm-spec/wm-spec.sgml index d396d01..e3ea8a8 100644 --- a/wm-spec/wm-spec.sgml +++ b/wm-spec/wm-spec.sgml @@ -15,8 +15,8 @@ Version -This is version 1.1 of the Extended Window Manager Hints (EWMH) spec, -updated 10 March 2001. +This is DRAFT version 1.2 of the Extended Window Manager Hints (EWMH) spec, +updated October 11 2001. @@ -616,6 +616,8 @@ _NET_WM_WINDOW_TYPE_DESKTOP, ATOM _NET_WM_WINDOW_TYPE_DOCK, ATOM _NET_WM_WINDOW_TYPE_TOOLBAR, ATOM _NET_WM_WINDOW_TYPE_MENU, ATOM +_NET_WM_WINDOW_TYPE_UTILITY, ATOM +_NET_WM_WINDOW_TYPE_SPLASH, ATOM _NET_WM_WINDOW_TYPE_DIALOG, ATOM _NET_WM_WINDOW_TYPE_NORMAL, ATOM ]]> @@ -631,7 +633,21 @@ window manager would keep such windows on top of all other windows. _NET_WM_WINDOW_TYPE_TOOLBAR and _NET_WM_WINDOW_TYPE_MENU indicate toolbar and -pinnable menu windows, respectively. +pinnable menu windows, respectively (i.e. toolbars and menus "torn off" from +the main application). Windows of this type may set the WM_TRANSIENT_FOR +hint indicating the main application window. + + +_NET_WM_WINDOW_TYPE_UTILITY indicates a small persistent utility window, such as +a palette or toolbox. It is distinct from type TOOLBAR because it does not +correspond to a toolbar torn off from the main application. It's distinct from +type DIALOG because it isn't a transient dialog, the user will probably keep it +open while they're working. Windows of this type may set the WM_TRANSIENT_FOR +hint indicating the main application window. + + +_NET_WM_WINDOW_TYPE_SPLASH indicates that the window is a splash screen +displayed as an application is starting up. _NET_WM_WINDOW_TYPE_DIALOG indicates that this is a dialog window. If @@ -669,6 +685,7 @@ _NET_WM_STATE_MAXIMIZED_HORZ, ATOM _NET_WM_STATE_SHADED, ATOM _NET_WM_STATE_SKIP_TASKBAR, ATOM _NET_WM_STATE_SKIP_PAGER, ATOM +_NET_WM_STATE_FULLSCREEN, ATOM ]]> An implementation MAY add new atoms to this list. Implementations @@ -694,14 +711,19 @@ _NET_WM_STATE_MAXIMIZED_{VERT,HORZ} indicates that the window is _NET_WM_STATE_SHADED indicates that the window is shaded. -_NET_WM_SKIP_TASKBAR indicates that the window should not be included on a +_NET_WM_STATE_SKIP_TASKBAR indicates that the window should not be included on a taskbar. -_NET_WM_SKIP_PAGER indicates that the window should not be included on a +_NET_WM_STATE_SKIP_PAGER indicates that the window should not be included on a pager. +_NET_WM_STATE_FULLSCREEN indicates that the window should fill the entire screen +and have no window decorations. For example, a presentation program would use +this hint. + + To change the state of a mapped window, a Client MUST send a _NET_WM_STATE client message to the root window (window is the respective window, type _NET_WM_STATE, format 32, l[0]=<the action, as listed below>, @@ -1222,6 +1244,12 @@ OR OTHER DEALINGS IN THE SOFTWARE. Specification and sample code for the content of WM_CLIENT_NAME(STRING). + + Added _NET_WM_WINDOW_TYPE_SPLASH, _NET_WM_WINDOW_TYPE_UTILITY. + + + Added _NET_WM_STATE_FULLSCREEN. + -- cgit v1.2.3-54-g00ecf From 98a7ec3fe47ed039e4eecb42f1b3b1abd2d908f0 Mon Sep 17 00:00:00 2001 From: hp Date: Thu, 18 Oct 2001 16:40:24 +0000 Subject: new window types, FULLSCREEN state --- wm-spec/wm-spec.sgml | 86 ++++++++++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 84 insertions(+), 2 deletions(-) diff --git a/wm-spec/wm-spec.sgml b/wm-spec/wm-spec.sgml index e3ea8a8..501823d 100644 --- a/wm-spec/wm-spec.sgml +++ b/wm-spec/wm-spec.sgml @@ -16,7 +16,7 @@ Version This is DRAFT version 1.2 of the Extended Window Manager Hints (EWMH) spec, -updated October 11 2001. +updated October 17 2001. @@ -741,7 +741,86 @@ _NET_WM_STATE_TOGGLE 2 /* toggle property */ See also the implementation notes on urgency and fixed size windows. - _NET_WM_STRUT + + + + _NET_WM_ALLOWED_ACTIONS + + +A list of atoms indicating user operations that the window manager supports for +this window. Atoms present in the list indicate allowed actions, atoms not +present in the list indicate actions that are not supported for this window. +The window manager MUST keep this property updated to reflect the +actions which are currently "active" or "sensitive" for a window. +Taskbars, pagers, and other tools use _NET_WM_ALLOWED_ACTIONS to +decide which actions should be made available to the user. + + +Possible atoms are: + + + +An implementation MAY add new atoms to this list. Implementations +without extensions MUST ignore any unknown atoms, effectively removing +them from the list. These extension atoms MUST NOT start with the prefix +_NET. + + +Note that the actions listed here are those that the window +manager will honor for this window. The operations must still be +requested through the normal mechanisms outlined in this specification. For +example, _NET_WM_ACTION_CLOSE does not mean that clients can send a +WM_DELETE_WINDOW message to this window; it means that clients can use a +_NET_CLOSE_WINDOW message to ask the window manager to do so. + + +Window managers SHOULD ignore the value of _NET_WM_ALLOWED_ACTIONS when they +initially manage a window. This value may be left over from a previous window +manager with different policies. + + +_NET_WM_ACTION_MOVE indicates that the window may be moved around the screen. + + +_NET_WM_ACTION_RESIZE indicates that the window may be resized. +(Implementation note: window managers can identify a non-resizable +window because its minimum and maximum size in WM_NORMAL_HINTS will be the same.) + + +_NET_WM_ACTION_SHADE indicates that the window may be shaded. + + +_NET_WM_ACTION_STICK indicates that the window may have its sticky state +toggled (as for _NET_WM_STATE_STICKY). Note that this state has to do with +viewports, not desktops. + + +_NET_WM_ACTION_MAXIMIZE_HORZ indicates that the window may be maximized horizontally. + + +_NET_WM_ACTION_MAXIMIZE_VERT indicates that the window may be maximized vertically. + + +_NET_WM_ACTION_CHANGE_DESKTOP indicates that the window may be moved between desktops. + + +_NET_WM_ACTION_CLOSE indicates that the window may be closed (i.e. a WM_DELETE_WINDOW +message may be sent). + + + +_NET_WM_STRUT @@ -1250,6 +1329,9 @@ OR OTHER DEALINGS IN THE SOFTWARE. Added _NET_WM_STATE_FULLSCREEN. + + Added _NET_WM_ALLOWED_ACTIONS. + -- cgit v1.2.3-54-g00ecf From adf432d1379fcbcc44703776f0ed26b4a9d2da2c Mon Sep 17 00:00:00 2001 From: hp Date: Thu, 18 Oct 2001 18:07:17 +0000 Subject: testing CVS server --- wm-spec/wm-spec.sgml | 1 + 1 file changed, 1 insertion(+) diff --git a/wm-spec/wm-spec.sgml b/wm-spec/wm-spec.sgml index 501823d..17ed1d3 100644 --- a/wm-spec/wm-spec.sgml +++ b/wm-spec/wm-spec.sgml @@ -1652,3 +1652,4 @@ Added _NET_WM_STATE_SKIP_TASKBAR
+ -- cgit v1.2.3-54-g00ecf From d2a732bb26a9c803b9e66c676f781fe2498f0455 Mon Sep 17 00:00:00 2001 From: hp Date: Sat, 9 Mar 2002 02:19:34 +0000 Subject: commit _NET_WM_STATE_HIDDEN docs, apparently I hadn't commited them before. --- wm-spec/wm-spec.sgml | 93 +++++++++++++++++++++++++++++++++++++++++++++++----- 1 file changed, 84 insertions(+), 9 deletions(-) diff --git a/wm-spec/wm-spec.sgml b/wm-spec/wm-spec.sgml index 17ed1d3..836997a 100644 --- a/wm-spec/wm-spec.sgml +++ b/wm-spec/wm-spec.sgml @@ -160,11 +160,13 @@ The first is to use multiple virtual roots (see ) desktop by manipulating the stacking order of the virtual roots. This is completely ICCCM compliant, but has the issues outlined in The second option is to keep all managed windows as children of the root -window and unmap the frames of those which are not on the current desktop. -This puts the clients in an undefined ICCCM state, since they are unviewable, -but not iconic. In practice, this seems to cause no problems and the ICCCM -compliant alternative to iconify all clients on non-current desktops (without -showing their icons) is clearly not acceptable. +window and unmap the frames of those which are not on the current +desktop. Unmapped windows should be placed in IconicState, according to +the ICCCM. Windows which are actually iconified or minimized +should have the _NET_WM_STATE_HIDDEN property set, to +communicate to pagers that the window should not be represented as +"onscreen." + @@ -685,6 +687,7 @@ _NET_WM_STATE_MAXIMIZED_HORZ, ATOM _NET_WM_STATE_SHADED, ATOM _NET_WM_STATE_SKIP_TASKBAR, ATOM _NET_WM_STATE_SKIP_PAGER, ATOM +_NET_WM_STATE_HIDDEN, ATOM _NET_WM_STATE_FULLSCREEN, ATOM ]]> @@ -711,13 +714,39 @@ _NET_WM_STATE_MAXIMIZED_{VERT,HORZ} indicates that the window is _NET_WM_STATE_SHADED indicates that the window is shaded. -_NET_WM_STATE_SKIP_TASKBAR indicates that the window should not be included on a -taskbar. +_NET_WM_STATE_SKIP_TASKBAR indicates that the window should not be +included on a taskbar. This hint should be requested by the +application, i.e. it indicates that the window by nature is never +in the taskbar. Applications should not set this hint if +_NET_WM_WINDOW_TYPE already conveys the exact nature of the +window. -_NET_WM_STATE_SKIP_PAGER indicates that the window should not be included on a -pager. +_NET_WM_STATE_SKIP_PAGER indicates that the window should not be +included on a pager. This hint should be requested by the application, +i.e. it indicates that the window by nature is never in the +pager. Applications should not set this hint if _NET_WM_WINDOW_TYPE +already conveys the exact nature of the window. + +_NET_WM_STATE_HIDDEN should be set by the window manager to indicate +that a window would not be visible on the screen if its +desktop/viewport were active and its coordinates were within the +screen bounds. The canonical example is that minimized windows should +be in the _NET_WM_STATE_HIDDEN state. Pagers and similar applications +should use _NET_WM_STATE_HIDDEN instead of WM_STATE to decide whether +to display a window in miniature representations of the windows on a +desktop. + + +Implementation note: if an application asks to toggle +_NET_WM_STATE_HIDDEN the window manager should probably just ignore +the request, since _NET_WM_STATE_HIDDEN is a function of some other +aspect of the window such as minimization, rather than an independent +state. + + + _NET_WM_STATE_FULLSCREEN indicates that the window should fill the entire screen and have no window decorations. For example, a presentation program would use @@ -1001,6 +1030,45 @@ unlikely to break anything, it seems reasonable to document it as standard. 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: + + + + If either _NET_WM_STATE_SKIP_PAGER or + _NET_WM_STATE_HIDDEN are set on a window, then the + pager should not show that window. + + + + + The pager may choose not to display windows with + certain semantic types; this spec has no + recommendations, but common practice is to avoid + displaying _NET_WM_WINDOW_TYPE_DOCK for example. + + + + + If the _NET_WM_STATE_SKIP_PAGER and + _NET_WM_STATE_HIDDEN hints are not present, and the + window manager claims to support _NET_WM_STATE_HIDDEN, + then the window should be shown if it's in either + NormalState or IconicState. + + + + + For window managers that do not support + _NET_WM_STATE_HIDDEN, the pager should + not show windows in IconicState. These window + managers are probably using an older version + of this specification. + + + + Window Movement @@ -1332,6 +1400,13 @@ OR OTHER DEALINGS IN THE SOFTWARE. Added _NET_WM_ALLOWED_ACTIONS. + + Added _NET_WM_STATE_HIDDEN and clarified purpose of + _NET_WM_STATE_SKIP_PAGER and _NET_WM_STATE_SKIP_TASKBAR. Changed + section on virtual desktop implementation to suggest ICCCM compliance + regarding IconicState, using _NET_WM_STATE_HIDDEN to avoid confusion. + Added implementation note for pagers on when to display a window. + -- cgit v1.2.3-54-g00ecf From 230e3c29e4b61dee242a06b72b00a8b2afc8b9c1 Mon Sep 17 00:00:00 2001 From: matthiasc Date: Sat, 18 May 2002 21:36:59 +0000 Subject: Extract version number and date into entities. --- wm-spec/wm-spec.sgml | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/wm-spec/wm-spec.sgml b/wm-spec/wm-spec.sgml index 836997a..4755f84 100644 --- a/wm-spec/wm-spec.sgml +++ b/wm-spec/wm-spec.sgml @@ -1,4 +1,6 @@ - + ]>
@@ -8,15 +10,15 @@ Extended Window Manager Hints -10 March 2001 +&date; +&version; Introduction Version -This is DRAFT version 1.2 of the Extended Window Manager Hints (EWMH) spec, -updated October 17 2001. +This is &version; of the Extended Window Manager Hints (EWMH) spec, updated &date;. -- cgit v1.2.3-54-g00ecf From 0a4f231136c6331b9dcc33d7ee80f42b8afef611 Mon Sep 17 00:00:00 2001 From: matthiasc Date: Sat, 18 May 2002 21:38:53 +0000 Subject: A customization for the html and print stylesheets (main difference to the default: section numbering is turned on). --- wm-spec/wm-spec.dsl | 44 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 44 insertions(+) create mode 100644 wm-spec/wm-spec.dsl diff --git a/wm-spec/wm-spec.dsl b/wm-spec/wm-spec.dsl new file mode 100644 index 0000000..a4b5f6c --- /dev/null +++ b/wm-spec/wm-spec.dsl @@ -0,0 +1,44 @@ + + +]> + + + +;; html customization goes here + +(define %root-filename% "index") +(define %html-ext% ".html") + + + + + + +;; print customization goes here + + + + + +;; common customization goes here + +(define %section-autolabel% #t) +(define %quanda-inherit-numeration% #t) +(define %generate-article-toc% #t) +(define (article-titlepage-recto-elements) + (list (normalize "title") + (normalize "subtitle") + (normalize "corpauthor") + (normalize "authorgroup") + (normalize "author") + (normalize "releaseinfo") + (normalize "date"))) + + + + + + + + -- cgit v1.2.3-54-g00ecf From 3d35ec42c00e4f4e3951e997cbfa71f5cdf2adb1 Mon Sep 17 00:00:00 2001 From: matthiasc Date: Tue, 11 Jun 2002 21:18:30 +0000 Subject: Applied moveresize and cleanup patches. --- wm-spec/wm-spec.sgml | 68 ++++++++++++++++++++++++++++++++++++++++++++++------ 1 file changed, 61 insertions(+), 7 deletions(-) diff --git a/wm-spec/wm-spec.sgml b/wm-spec/wm-spec.sgml index 4755f84..da7c231 100644 --- a/wm-spec/wm-spec.sgml +++ b/wm-spec/wm-spec.sgml @@ -1,6 +1,6 @@ - + ]>
@@ -496,12 +496,24 @@ _NET_WM_MOVERESIZE data.l[0] = x_root data.l[1] = y_root data.l[2] = direction + data.l[3] = button ]]> - This message allows an application to initiate window movement or resizing. This allows the application to define its own move and size "grips", whilst letting the window manager control the actual move/resize. This means that all moves / resizes can happen in a consistent manner as defined by the WM. + This message allows an application to initiate window movement or + resizing. This allows the application to define its own move and size + "grips", whilst letting the window manager control the actual operation. + This means that all moves/resizes can happen in a consistent manner as + defined by the WM. - When sending this message, x_root and y_root MUST indicate the position of the mouse click with respect to the root window and direction MUST indicate whether this is a move or resize event, and if it is a resize event, which edges of the window the size grip applies to. + When sending this message in response to a button press event, button + SHOULD indicate the button which was pressed, x_root and y_root MUST + indicate the position of the button press with respect to the root + window and direction MUST indicate whether this is a move or resize + event, and if it is a resize event, which edges of the window the size + grip applies to. When sending this message in response to a key event, + the direction MUST indicate wether this this is a move or resize event + and the other fields are unused. - The client MUST release all grabs on Pointer events, prior to sending such message. + The Client MUST release all grabs prior to sending such message. + + The Window Manager can use the button field to determine the + events on which it terminates the operation initiated by the + _NET_WM_MOVERESIZE message. Since there is a race condition between + client sending the _NET_WM_MOVERESIZE message and the user releasing + the button, Window Managers are advised to offer some other means to + terminate the operation, e.g. by pressing the ESC key. + @@ -576,8 +598,20 @@ indicates that the window SHOULD appear on all desktops/workspaces. The Window Manager should honor _NET_WM_DESKTOP whenever a withdrawn window -requests to be mapped. +requests to be mapped. + + +The Window Manager should remove the property whenever +a window is withdrawn, but it should leave the property in place when it is +shutting down, e.g. in response to losing ownership of the WM_Sn manager +selection. + +Rationale: Removing the property upon window withdrawal helps legacy +applications which want to reuse withdrawn windows. Not removing the property +upon shutdown allows the next Window Manager to restore windows to their +previous desktops. + A Client can request a change of desktop for a non-withdrawn window by sending a _NET_WM_DESKTOP client message to the root window: @@ -678,6 +712,18 @@ wishing to change the state of a window MUST send a _NET_WM_STATE client message to the root window (see below). The Window Manager MUST keep this property updated to reflect the current state of the window. + +The Window Manager should remove the property whenever +a window is withdrawn, but it should leave the property in place when it is +shutting down, e.g. in response to losing ownership of the WM_Sn manager +selection. + + +Rationale: Removing the property upon window withdrawal helps legacy +applications which want to reuse withdrawn windows. Not removing the property +upon shutdown allows the next Window Manager to restore windows to their +previous state. + Possible atoms are: @@ -1328,7 +1374,7 @@ int net_get_hostname (char *buf, size_t maxlen) Copyright -Copyright (C) 2000 See Contributors List +Copyright (C) 2000, 2001, 2002 See Contributors List Permission is hereby granted, free of charge, to any person @@ -1409,6 +1455,14 @@ OR OTHER DEALINGS IN THE SOFTWARE. regarding IconicState, using _NET_WM_STATE_HIDDEN to avoid confusion. Added implementation note for pagers on when to display a window. + + Added button field and new directions for keyboard-initiated actions + to the _NET_WM_MOVERESIZE message. + + + Added advice on removing _NET_WM_STATE and _NET_WM_DESKTOP when a window + is withdrawn. + -- cgit v1.2.3-54-g00ecf From e0d503888872804a772b1479cbeb0934a01347a2 Mon Sep 17 00:00:00 2001 From: matthiasc Date: Mon, 19 Aug 2002 20:53:30 +0000 Subject: Moving towards EWMH 1.2. --- wm-spec/wm-spec.sgml | 213 ++++++++++++++++++++++++++++++++++++++++++++++----- 1 file changed, 192 insertions(+), 21 deletions(-) diff --git a/wm-spec/wm-spec.sgml b/wm-spec/wm-spec.sgml index da7c231..1727454 100644 --- a/wm-spec/wm-spec.sgml +++ b/wm-spec/wm-spec.sgml @@ -1,6 +1,6 @@ - + ]>
@@ -166,7 +166,7 @@ window and unmap the frames of those which are not on the current desktop. Unmapped windows should be placed in IconicState, according to the ICCCM. Windows which are actually iconified or minimized should have the _NET_WM_STATE_HIDDEN property set, to -communicate to pagers that the window should not be represented as +communicate to Pagers that the window should not be represented as "onscreen." @@ -216,14 +216,27 @@ manipulated within their parent window just like ordinary top-level windows on the root window. +Layered stacking order + +Some Window Managers keep the toplevel windows not in a single linear stack, +but subdivide the stack into several layers. There is a lot of variation +among the features of layered stacking order implementations. The number of +layers may or may not be fixed. The layer of a toplevel window may be explicit +and directly modifyable or derived from other properties of the window, e.g. +the type of the window. The stacking order may or may not +be strict, i.e. not allow the user to raise or lower windows beyond their +layer. + + + Scope of this spec This spec tries to address the following issues: Allow clients to influence their initial state with respect -to maximization, shading, stickyness, desktop. +to maximization, shading, stickyness, desktop, stacking order. Improve the Window Managers ability to vary window -decorations by allowing clients to hint the Window Manager about the type -of their windows. +decorations and maintain the stacking order by allowing clients to hint the +Window Manager about the type of their windows. Enable pagers and taskbars to be implemented as separate clients and allow them to work with any compliant Window Manager. @@ -232,7 +245,6 @@ clients and allow them to work with any compliant Window Manager.Other IPC mechanisms like ICE or Corba. Window Manager configuration. Window Manager documentation. -Geometry between desktops. Clients appearing on a proper subset of desktops. Window-in-window MDI. @@ -340,7 +352,7 @@ _NET_DESKTOP_VIEWPORT x, y, CARDINAL[][2]/32 ]]> Array of pairs of cardinals that define the top left corner of each desktops -viewport. For window managers that don't support large desktops, this MUST +viewport. For Window Managers that don't support large desktops, this MUST always be set to (0,0). @@ -401,7 +413,7 @@ _NET_ACTIVE_WINDOW, WINDOW/32 The window ID of the currently active window or None if no window has the focus. This is a read-only property set by the -window manager. If a client (for example, a taskbar) wants to activate +Window Manager. If a client (for example, a taskbar) wants to activate another window, it MUST send a _NET_ACTIVE_WINDOW client message to the root window: @@ -425,7 +437,7 @@ completely contained within the viewport. Work area SHOULD be used by desktop applications to place desktop icons appropriately. - The window manager SHOULD calculate this space by taking the current page minus space occupied by dock and panel windows, as indicated by the _NET_WM_STRUT property set on client windows. + The Window Manager SHOULD calculate this space by taking the current page minus space occupied by dock and panel windows, as indicated by the _NET_WM_STRUT property set on client windows. @@ -441,12 +453,12 @@ The Window Manager MUST set this property on the root window to be the ID of a have the _NET_WM_NAME property set to the name of the Window Manager. -Rationale: The child window is used to distinguish an active window manager +Rationale: The child window is used to distinguish an active Window Manager from a stale _NET_SUPPORTING_WM_CHECK property that happens to point to another window. If the _NET_SUPPORTING_WM_CHECK window on the client window is missing or not properly set, clients SHOULD assume that no conforming - window manager is present. + Window Manager is present. @@ -463,6 +475,138 @@ virtual roots and allows clients to figure out the WM frame windows of their windows. + + _NET_DESKTOP_LAYOUT + + #define _NET_WM_ORIENTATION_HORZ 0 + #define _NET_WM_ORIENTATION_VERT 1 + + #define _NET_WM_TOPLEFT 0 + #define _NET_WM_TOPRIGHT 1 + #define _NET_WM_BOTTOMRIGHT 2 + #define _NET_WM_BOTTOMLEFT 3 + + + This property is set by a Pager, not by the Window + Manager. + When setting this property, the Pager must own a manager selection (as + defined in the ICCCM 2.8). The manager selection is called + _NET_DESKTOP_LAYOUT_Sn where + n is the screen number. The purpose of + this property is to allow the Window Manager to know the desktop + layout displayed by the Pager. + + + _NET_DESKTOP_LAYOUT describes the layout of virtual + desktops relative to each other. More specifically, it describes the layout + used by the owner of the manager selection. The Window Manager may use + this layout information or may choose to ignore it. + The property contains four values: the Pager orientation, the number of + desktops in the X direction, the number in the Y direction, and the + starting corner of the layout, i.e. the corner containing the first desktop. + + + Note: In order to interoperate with Pagers implementing an earlier + draft of this document, Window Managers should accept a + _NET_DESKTOP_LAYOUT property of length 3 and + use _NET_WM_TOPLEFT as the starting corner in this case. + + + The virtual desktops are arranged in a rectangle + with X rows and Y columns. If X times Y does not match the total number of + desktops as specified by + _NET_NUMBER_OF_DESKTOPS, the highest-numbered + workspaces are assumed to be nonexistent. Either X or Y (but not + both) may be specified as 0 in which case its actual value will be + derived from _NET_NUMBER_OF_DESKTOPS. + + + When the orientation is _NET_WM_ORIENTATION_HORZ + the desktops are layed out in rows, with the first desktop in the + specified starting corner. So a layout with X=4 and Y=3 starting in + the _NET_WM_TOPLEFT corner looks like this: + + +--+--+--+--+ + | 0| 1| 2| 3| + +--+--+--+--+ + | 4| 5| 6| 7| + +--+--+--+--+ + | 8| 9|10|11| + +--+--+--+--+ + +With starting_corner _NET_WM_BOTTOMRIGHT, it looks like +this: + + +--+--+--+--+ + |11|10| 9| 8| + +--+--+--+--+ + | 7| 6| 5| 4| + +--+--+--+--+ + | 3| 2| 1| 0| + +--+--+--+--+ + + + + + + When the orientation is _NET_WM_ORIENTATION_VERT + the layout for X=4 and Y=3 starting in the _NET_WM_TOPLEFT + corner looks like: + + + +--+--+--+--+ + | 0| 3| 6| 9| + +--+--+--+--+ + | 1| 4| 7|10| + +--+--+--+--+ + | 2| 5| 8|11| + +--+--+--+--+ + +With starting_corner _NET_WM_TOPRIGHT, it looks like: + + + +--+--+--+--+ + | 9| 6| 3| 0| + +--+--+--+--+ + |10| 7| 4| 1| + +--+--+--+--+ + |11| 8| 5| 2| + +--+--+--+--+ + + + + The numbers here are the desktop numbers, as for + _NET_CURRENT_DESKTOP. + + + + _NET_SHOWING_DESKTOP + + + Some Window Managers have a "showing the desktop" mode in which windows + are hidden, and the desktop background is displayed and focused. If a + Window Manager supports the _NET_SHOWING_DESKTOP hint, it MUST set it + to a value of 1 if the Window Manager is in "showing the desktop" mode, + and a value of zero if the Window Manager is not in this mode. + + + If a Pager wants to enter or leave the mode, it MUST + send a _NET_SHOWING_DESKTOP client message to the root window + requesting the change: + + The Window Manager may choose to ignore this client message. + + + Other Root Window Messages @@ -485,7 +629,7 @@ _NET_CLOSE_WINDOW The Window Manager MUST then attempt to close the window specified. - Rationale: A window manager might be more clever than the usual method (send WM_DELETE message if the protocol is selected, XKillClient otherwise). It might introduce a timeout, for example. Instead of duplicating the code, the Window Manager can easily do the job. + Rationale: A Window Manager might be more clever than the usual method (send WM_DELETE message if the protocol is selected, XKillClient otherwise). It might introduce a timeout, for example. Instead of duplicating the code, the Window Manager can easily do the job. _NET_WM_MOVERESIZE _NET_WM_DESKTOP , CARDINAL/32 +_NET_WM_DESKTOP desktop, CARDINAL/32 ]]> Cardinal to determine the desktop the window is in (or wants to be) starting @@ -737,6 +881,7 @@ _NET_WM_STATE_SKIP_TASKBAR, ATOM _NET_WM_STATE_SKIP_PAGER, ATOM _NET_WM_STATE_HIDDEN, ATOM _NET_WM_STATE_FULLSCREEN, ATOM +_NET_WM_STATE_FLOATING, ATOM ]]> An implementation MAY add new atoms to this list. Implementations @@ -771,9 +916,9 @@ window. _NET_WM_STATE_SKIP_PAGER indicates that the window should not be -included on a pager. This hint should be requested by the application, +included on a Pager. This hint should be requested by the application, i.e. it indicates that the window by nature is never in the -pager. Applications should not set this hint if _NET_WM_WINDOW_TYPE +Pager. Applications should not set this hint if _NET_WM_WINDOW_TYPE already conveys the exact nature of the window. @@ -800,6 +945,14 @@ _NET_WM_STATE_FULLSCREEN indicates that the window should fill the entire screen and have no window decorations. For example, a presentation program would use this hint. + +_NET_WM_STATE_FLOATING indicates that the window should be on top of other +windows of the same type. Applications should not set this hint +if _NET_WM_WINDOW_TYPE already conveys the exact nature of the window. +Windows in this state would typically appear above other windows of the same +_NET_WM_WINDOW_TYPE. + + To change the state of a mapped window, a Client MUST send a _NET_WM_STATE client message to the root window (window is the respective window, type @@ -831,7 +984,7 @@ this window. Atoms present in the list indicate allowed actions, atoms not present in the list indicate actions that are not supported for this window. The window manager MUST keep this property updated to reflect the actions which are currently "active" or "sensitive" for a window. -Taskbars, pagers, and other tools use _NET_WM_ALLOWED_ACTIONS to +Taskbars, Pagers, and other tools use _NET_WM_ALLOWED_ACTIONS to decide which actions should be made available to the user. @@ -844,6 +997,7 @@ _NET_WM_ACTION_SHADE, ATOM _NET_WM_ACTION_STICK, ATOM _NET_WM_ACTION_MAXIMIZE_HORZ, ATOM _NET_WM_ACTION_MAXIMIZE_VERT, ATOM +_NET_WM_ACTION_FULLSCREEN, ATOM _NET_WM_ACTION_CHANGE_DESKTOP, ATOM _NET_WM_ACTION_CLOSE, ATOM ]]> @@ -854,15 +1008,15 @@ them from the list. These extension atoms MUST NOT start with the prefix _NET. -Note that the actions listed here are those that the window -manager will honor for this window. The operations must still be +Note that the actions listed here are those that the Window +Manager will honor for this window. The operations must still be requested through the normal mechanisms outlined in this specification. For example, _NET_WM_ACTION_CLOSE does not mean that clients can send a WM_DELETE_WINDOW message to this window; it means that clients can use a -_NET_CLOSE_WINDOW message to ask the window manager to do so. +_NET_CLOSE_WINDOW message to ask the Window Manager to do so. -Window managers SHOULD ignore the value of _NET_WM_ALLOWED_ACTIONS when they +Window Managers SHOULD ignore the value of _NET_WM_ALLOWED_ACTIONS when they initially manage a window. This value may be left over from a previous window manager with different policies. @@ -889,6 +1043,10 @@ _NET_WM_ACTION_MAXIMIZE_HORZ indicates that the window may be maximized horizont _NET_WM_ACTION_MAXIMIZE_VERT indicates that the window may be maximized vertically. +_NET_WM_ACTION_FULLSCREEN indicates that the window may be brought to + fullscreen mode. + + _NET_WM_ACTION_CHANGE_DESKTOP indicates that the window may be moved between desktops. @@ -1312,7 +1470,11 @@ was the frame for this window. 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 the next revision of this specification. + 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. @@ -1463,6 +1625,15 @@ OR OTHER DEALINGS IN THE SOFTWARE. Added advice on removing _NET_WM_STATE and _NET_WM_DESKTOP when a window is withdrawn. + + Added _NET_DESKTOP_LAYOUT to allow a Pager to specify inter-desktop geometry. + + + Added _NET_SHOWING_DESKTOP. + + + Added _NET_WM_STATE_FLOATING. + -- cgit v1.2.3-54-g00ecf From bc84ce20c028d238da65f42fecb8494c4d8b5585 Mon Sep 17 00:00:00 2001 From: matthiasc Date: Fri, 6 Sep 2002 23:21:51 +0000 Subject: New draft. --- wm-spec/wm-spec.sgml | 165 +++++++++++++++++++++++++++++++++++++++------------ 1 file changed, 126 insertions(+), 39 deletions(-) diff --git a/wm-spec/wm-spec.sgml b/wm-spec/wm-spec.sgml index 1727454..0961ce4 100644 --- a/wm-spec/wm-spec.sgml +++ b/wm-spec/wm-spec.sgml @@ -1,6 +1,6 @@ - + ]>
@@ -26,10 +26,11 @@ This is &version; of the Extended Window Manager Hints (EWMH) spec, updated &dat This spec defines interactions between window managers, applications, and the utilities that form part of a desktop environment. It builds -on the ICCCM [2], which defines WM (window manager) interactions at a -lower level. The ICCCM does not provide ways to implement many -features that modern desktop users expect. The GNOME and KDE desktop -projects originally developed their own extensions to the ICCCM to +on the Inter-Client Communication Conventions Manual ICCCM, which defines +window manager interactions at a lower level. The ICCCM does not provide ways +to implement many features that modern desktop users expect. The GNOME and KDE +desktop projects originally developed their own extensions to the ICCCM to support these features; this spec replaces those custom extensions with a standardized set of ICCCM additions that any desktop environment can adopt. @@ -46,7 +47,7 @@ interpreted as described in RFC 2119. The key words "Window Manager" refer to a window manager which is adopting this specification. "Pager" refers to desktop utility applications, including pagers and taskbars. "Application" refers to other clients. "Clients" refers -to Pagers + Applications ie. all X clients, except for the Window Manager. +to Pagers and Applications ie. all X clients, except for the Window Manager. @@ -260,7 +261,7 @@ argument). - Root Window Properties (+Related Messages) + Root Window Properties (and Related Messages) Whenever this spec speaks about sending a message to the root window, it is understood that the client is supposed to create @@ -390,7 +391,9 @@ _NET_CURRENT_DESKTOP _NET_DESKTOP_NAMES, UTF8_STRING[] ]]> -The names of all virtual desktops. This is a list of NULL-terminated strings in UTF-8 [1] encoding. This property MAY be changed by a Pager or the Window Manager at any time. +The names of all virtual desktops. This is a list of NULL-terminated strings in + UTF-8 encoding UTF8. This property MAY be + changed by a Pager or the Window Manager at any time. Note: The number of names could be different from _NET_NUMBER_OF_DESKTOPS. @@ -631,7 +634,37 @@ The Window Manager MUST then attempt to close the window specified. Rationale: A Window Manager might be more clever than the usual method (send WM_DELETE message if the protocol is selected, XKillClient otherwise). It might introduce a timeout, for example. Instead of duplicating the code, the Window Manager can easily do the job. - _NET_WM_MOVERESIZE + + _NET_MOVERESIZE_WINDOW + + + Pagers wanting to move or resize a window may send a + _NET_MOVERESIZE_WINDOW client message request to the root window + instead of using a ConfigureRequest. + + + Window Managers should treat a _NET_MOVERESIZE_WINDOW message exactly + like a ConfigureRequest (in particular, adhere to the ICCCM rules about + synthetic ConfigureNotify events), except that they should use the + gravity specified in the message. + + + Rationale: Using a _NET_MOVERESIZE_WINDOW message with StaticGravity + allows Pagers to exactly position and resize a window including its + decorations without knowing the size of the decorations. + + + _NET_WM_MOVERESIZE An implementation MAY add new atoms to this list. Implementations @@ -930,27 +964,34 @@ be in the _NET_WM_STATE_HIDDEN state. Pagers and similar applications should use _NET_WM_STATE_HIDDEN instead of WM_STATE to decide whether to display a window in miniature representations of the windows on a desktop. - + -Implementation note: if an application asks to toggle -_NET_WM_STATE_HIDDEN the window manager should probably just ignore +Implementation note: if an Application asks to toggle +_NET_WM_STATE_HIDDEN the Window Manager should probably just ignore the request, since _NET_WM_STATE_HIDDEN is a function of some other aspect of the window such as minimization, rather than an independent state. - - -_NET_WM_STATE_FULLSCREEN indicates that the window should fill the entire screen -and have no window decorations. For example, a presentation program would use -this hint. +_NET_WM_STATE_FULLSCREEN indicates that the window should fill the entire + screen and have no window decorations. For example, a presentation + program would use this hint. -_NET_WM_STATE_FLOATING indicates that the window should be on top of other -windows of the same type. Applications should not set this hint -if _NET_WM_WINDOW_TYPE already conveys the exact nature of the window. -Windows in this state would typically appear above other windows of the same -_NET_WM_WINDOW_TYPE. +_NET_WM_STATE_ABOVE indicates that the window should be on top of most +windows (see for details). + + + +_NET_WM_STATE_BELOW indicates that the window should be below most +windows (see for details). + + + + _NET_WM_STATE_ABOVE and _NET_WM_STATE_BELOW are mainly meant for user + preferences and should not be used by applications e.g. for drawing + attention to their dialogs (the Urgency + hint should be used in that case, see ).' @@ -993,6 +1034,7 @@ Possible atoms are: +_NET_WM_ACTION_MINIMIZE indicates that the window may be iconified. + + _NET_WM_ACTION_SHADE indicates that the window may be shaded. @@ -1044,7 +1089,7 @@ _NET_WM_ACTION_MAXIMIZE_VERT indicates that the window may be maximized vertical _NET_WM_ACTION_FULLSCREEN indicates that the window may be brought to - fullscreen mode. + fullscreen state. _NET_WM_ACTION_CHANGE_DESKTOP indicates that the window may be moved between desktops. @@ -1287,7 +1332,8 @@ document offers the following clarifications: Window managers MUST honour the win_gravity field of WM_NORMAL_HINTS - for both MapRequest _and_ ConfigureRequest events [1] + for both MapRequest _and_ ConfigureRequest events (ICCCM Version 2.0, + §4.1.2.3 and §4.1.5) Applications are free to change their win_gravity setting at any time @@ -1305,7 +1351,7 @@ corner of the frame. When generating synthetic ConfigureNotify events, the position given MUST be the top-left corner of the client window in relation to the - origin of the root window (i.e., ignoring win_gravity) [2] + origin of the root window (i.e., ignoring win_gravity) (ICCCM Version 2.0, §4.2.3) XMoveWindow(w,x,y) behaviour depends on the window gravity. Upon receiving a @@ -1460,12 +1506,6 @@ initial window's width should be taken into consideration, as if it was the frame for this window. - -[1] ICCCM Version 2.0, §4.1.2.3 and §4.1.5 - - -[2] ICCCM Version 2.0, §4.2.3 - Window-in-Window MDI @@ -1522,16 +1562,56 @@ int net_get_hostname (char *buf, size_t maxlen) ]]> + + + Stacking order + + To obtain good interoperability between different Desktop Environments, + the following layered stacking order is recommended, from the bottom: + + windows of type _NET_WM_TYPE_DESKTOP + windows having state _NET_WM_STATE_BELOW + windows not belonging in any other layer + windows of type _NET_WM_TYPE_DOCK (unless they have + state _NET_WM_TYPE_BELOW) and windows having state + _NET_WM_STATE_ABOVE + focused windows having state + _NET_WM_STATE_FULLSCREEN + + + + Windows that are transient for another window should be kept + above this window. + + + The window manager may choose to put some windows in different + stacking position, for example to allow user to bring currently active + window to the top and return it back when the window looses focus. + + References - -[1] F. Yergeau,"UTF-8, a transformation format of ISO 10646", RFC 2279 + + + [UTF8] + + + F. Yergeau,"UTF-8, a transformation format of ISO 10646", RFC 2279 - -[2] David Rosenthal / Stuart W. Marks "Inter-Client Communication Conventions - Manual (Version 2.0)", X Consortium Standard, X Version 11, Release 6.3 + + + + [ICCCM] + + + David Rosenthal and Stuart W. Marks, "Inter-Client Communication + Conventions Manual (Version 2.0)", X Consortium Standard, X Version 11, + Release 6.3 + + + Copyright @@ -1632,8 +1712,15 @@ OR OTHER DEALINGS IN THE SOFTWARE. Added _NET_SHOWING_DESKTOP. - Added _NET_WM_STATE_FLOATING. - + Added _NET_WM_STATE_ABOVE and _NET_WM_STATE_BELOW and a recommended layered + stacking order. + + + Added _NET_MOVERESIZE_WINDOW. + + + Improve markup of citations. + -- cgit v1.2.3-54-g00ecf From 1626b82163c6ad6b567af6f5e6028ea0491ff105 Mon Sep 17 00:00:00 2001 From: matthiasc Date: Sat, 7 Sep 2002 18:02:32 +0000 Subject: Fix a few typos. --- wm-spec/wm-spec.sgml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/wm-spec/wm-spec.sgml b/wm-spec/wm-spec.sgml index 0961ce4..7836064 100644 --- a/wm-spec/wm-spec.sgml +++ b/wm-spec/wm-spec.sgml @@ -53,7 +53,7 @@ to Pagers and Applications ie. all X clients, except for the Window Manager. Prerequisites for adoption of this specification -Window Managers and Clients which aim to fulfil this specification MUST adhere +Window Managers and Clients which aim to fulfill this specification MUST adhere to the ICCCM on which this specification builds. If this specification explicitly modifies the ICCCM Window Managers and Clients MUST fulfil these modifications. @@ -92,7 +92,7 @@ sometimes be useful. Shading Some Desktop Environments offer shading (also known as rollup) as an alternative to -iconfication. A shaded window typically shows only the titlebar, the client +iconification. A shaded window typically shows only the titlebar, the client window is hidden, thus shading is not useful for windows which are not decorated with a titlebar. @@ -223,7 +223,7 @@ Some Window Managers keep the toplevel windows not in a single linear stack, but subdivide the stack into several layers. There is a lot of variation among the features of layered stacking order implementations. The number of layers may or may not be fixed. The layer of a toplevel window may be explicit -and directly modifyable or derived from other properties of the window, e.g. +and directly modifiable or derived from other properties of the window, e.g. the type of the window. The stacking order may or may not be strict, i.e. not allow the user to raise or lower windows beyond their layer. -- cgit v1.2.3-54-g00ecf From 7a03fdebe838095055070362a1bfb9fcddc20aa6 Mon Sep 17 00:00:00 2001 From: matthiasc Date: Mon, 16 Sep 2002 22:46:03 +0000 Subject: EWMH draft update. --- wm-spec/wm-spec.sgml | 40 +++++++++++++++++++++++++++++----------- 1 file changed, 29 insertions(+), 11 deletions(-) diff --git a/wm-spec/wm-spec.sgml b/wm-spec/wm-spec.sgml index 7836064..4a2d4b9 100644 --- a/wm-spec/wm-spec.sgml +++ b/wm-spec/wm-spec.sgml @@ -1,6 +1,6 @@ - + ]>
@@ -328,8 +328,10 @@ If the number of desktops is shrinking and _NET_CURRENT_DESKTOP is out of the ne _NET_DESKTOP_GEOMETRY width, height, CARDINAL[2]/32 ]]> -Array of two cardinals that defines the common size of all desktops. -This property SHOULD be set by the Window Manager. + Array of two cardinals that defines the common size of all desktops + (this is equal to the screen size if the Window Manager doesn't support + large desktops, otherwise it's equal to the virtual size of the + desktop). This property SHOULD be set by the Window Manager. A Pager can request a change in the desktop geometry by sending a _NET_DESKTOP_GEOMETRY client @@ -641,12 +643,21 @@ _NET_MOVERESIZE_WINDOW window = window to be moved or resized message_type = _NET_MOVERESIZE_WINDOW format = 32 - data.l[0] = gravity - data.l[1] = x + data.l[0] = gravity and flags + data.l[1] = x data.l[2] = y data.l[3] = width data.l[4] = height ]]> + + The low byte of data.l[0] contains the gravity to use; it may contain + any value allowed for the WM_SIZE_HINTS.win_gravity property: + NorthWest (1), North (2), NorthEast (3), West (4), Center (5), East + (6), SouthWest (7), South (8), SouthEast (9) and Static (10). A + gravity of 0 indicates that the Window Manager should use the gravity + specified in WM_SIZE_HINTS.win_gravity. The bits 8 to 11 indicate the + presence of x, y, width and height. + Pagers wanting to move or resize a window may send a _NET_MOVERESIZE_WINDOW client message request to the root window @@ -1526,11 +1537,11 @@ 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: +WM_CLIENT_MACHINE is usually set by calling XSetWMProperties(). The hostname for the current host can be be retrieved using gethostname(), when gethostname() +is not available on the platform implementors may use the value of the +nodename field of struct utsname as returned by uname(). Note also that the value of WM_CLIENT_MACHINE is not guaranteed +to be a fully fully-qualified domain name of the host. An example of how to +retrieve the hostname: Greg Badros Matthias Clasen David Rosenthal - + Lubos Lunak Change history @@ -1721,6 +1732,13 @@ OR OTHER DEALINGS IN THE SOFTWARE. Improve markup of citations. + + Explain _NET_DESKTOP_GEOMETRY in more detail and improve the explanation + of WM_CLIENT_MACHINE in . + + + Add Lubos Lunak to the list of contributors. + -- cgit v1.2.3-54-g00ecf From 687976bc5562b632e5e69326334ce4545980b7d5 Mon Sep 17 00:00:00 2001 From: matthiasc Date: Tue, 17 Sep 2002 17:10:35 +0000 Subject: Yet another draft update. --- wm-spec/wm-spec.sgml | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/wm-spec/wm-spec.sgml b/wm-spec/wm-spec.sgml index 4a2d4b9..ad2cc55 100644 --- a/wm-spec/wm-spec.sgml +++ b/wm-spec/wm-spec.sgml @@ -1,6 +1,6 @@ - + ]>
@@ -1196,11 +1196,12 @@ See also the implementation notes on killing hung _NET_WM_HANDLED_ICONS ]]> -This property can be set by clients to indicate that the Window Manager need -not provide icons for iconified windows, for example if the client is a taskbar -and provides buttons for iconified windows. + This property can be set by a Pager on one of its own toplevel windows + to indicate that the Window Manager need not provide icons for + iconified windows, for example if it is a taskbar and provides buttons + for iconified windows. - + Window Manager Protocols @@ -1733,8 +1734,9 @@ OR OTHER DEALINGS IN THE SOFTWARE. Improve markup of citations. - Explain _NET_DESKTOP_GEOMETRY in more detail and improve the explanation - of WM_CLIENT_MACHINE in . + Explain _NET_DESKTOP_GEOMETRY and _NET_WM_HANDLED_ICONS in more detail and + improve the explanation of WM_CLIENT_MACHINE in + . Add Lubos Lunak to the list of contributors. -- cgit v1.2.3-54-g00ecf From d10d819f39c4c7e878288192f14248536d9d4b96 Mon Sep 17 00:00:00 2001 From: matthiasc Date: Sun, 6 Oct 2002 22:17:37 +0000 Subject: EWMH 1.2 final. --- wm-spec/wm-spec.sgml | 256 ++++++++++++++++++++++++++------------------------- 1 file changed, 131 insertions(+), 125 deletions(-) diff --git a/wm-spec/wm-spec.sgml b/wm-spec/wm-spec.sgml index ad2cc55..8f54a80 100644 --- a/wm-spec/wm-spec.sgml +++ b/wm-spec/wm-spec.sgml @@ -1,6 +1,6 @@ - + + ]>
@@ -55,31 +55,31 @@ to Pagers and Applications ie. all X clients, except for the Window Manager. Window Managers and Clients which aim to fulfill this specification MUST adhere to the ICCCM on which this specification builds. If this specification -explicitly modifies the ICCCM Window Managers and Clients MUST fulfil these +explicitly modifies the ICCCM Window Managers and Clients MUST fulfill these modifications. Non-ICCCM features -There is a number of window management features or behaviours which are -not specified in the ICCCM, but are commonly met in modern Window Managers and Desktop Environments. +There is a number of window management features or behaviors which are +not specified in the ICCCM, but are commonly met in modern window managers and desktop environments. Additional States -The ICCCM allows Window Managers to implement additional window states, which will +The ICCCM allows window managers to implement additional window states, which will appear to clients as substates of NormalState and IconicState. Two -commonly met examples are Maximized and Shaded. A Window Manager may implement these +commonly met examples are Maximized and Shaded. A window manager may implement these as proper substates of NormalState and IconicState, or it may treat them as independent flags, allowing e.g. a maximized window to be iconified and to re-appear as maximized upon de-iconification. Maximization -Maximization is a very old feature of Window Managers. There was even a ZoomedState +Maximization is a very old feature of window managers. There was even a ZoomedState in early ICCCM drafts. Maximizing a window should give it as much of the screen area as possible (this may not be the full screen area, but only -a smaller 'workarea', since the Window Manager may have reserved certain areas for other -windows). A Window Manager is expected to remember the geometry of a maximized window -and restore it upon de-maximization. Modern Window Managers typically allow separate +a smaller 'workarea', since the window manager may have reserved certain areas for other +windows). A window manager is expected to remember the geometry of a maximized window +and restore it upon de-maximization. Modern window managers typically allow separate horizontal and vertical maximization. With the introduction of the Xinerama extension in X11 R6.4, maximization has become more involved. Xinerama allows a screen to span multiple @@ -91,7 +91,7 @@ sometimes be useful. Shading -Some Desktop Environments offer shading (also known as rollup) as an alternative to +Some desktop environments offer shading (also known as rollup) as an alternative to iconification. A shaded window typically shows only the titlebar, the client window is hidden, thus shading is not useful for windows which are not decorated with a titlebar. @@ -99,26 +99,26 @@ decorated with a titlebar. Modality -The Window Manager _TRANSIENT_FOR hint of the ICCCM allows clients to specify that a +The WM_TRANSIENT_FOR hint of the ICCCM allows clients to specify that a toplevel window may be closed before the client finishes. A typical example of a transient window is a dialog. Some dialogs can be open for a long time, while the user continues to work in the main window. Other dialogs have to be closed before the user can continue to work in the main window. This property is called modality. While clients can implement modal windows in an ICCCM -compliant way using the globally active input model, some Window Managers offer support +compliant way using the globally active input model, some window managers offer support for handling modality. Large Desktops -The Window Manager may offer to arrange the managed windows on a desktop that is +The window manager may offer to arrange the managed windows on a desktop that is larger than the root window. The screen functions as a viewport on this large desktop. Different policies regarding the positioning of the viewport on the -desktop can be implemented: The Window Manager may only allow to change the viewport -position in increments of the screen size (paging) or it may allow arbitrary -positions (scrolling). +desktop can be implemented: The window manager may only allow the viewport +position to change in increments of the screen size (paging) or it may allow +arbitrary positions (scrolling). To fulfill the ICCCM principle that clients should behave the same -regardless wether a Window Manager is running or not, Window Managers which +regardless whether a window manager is running or not, window managers which implement large desktops must interpret all client-provided geometries with respect to the current viewport. @@ -132,28 +132,28 @@ large window (somewhat inappropriately called a 'virtual root'). Moving the viewport is then achieved by moving the virtual root in the opposite direction. Both alternatives are completely ICCCM compliant, although the second one -may be somewhat problematic for clients trying to figure out the Window Manager decorations +may be somewhat problematic for clients trying to figure out the window manager decorations around their toplevel windows and for clients trying to draw background images on the root window. Sticky windows -A Window Manager which implements a large desktop typically offers a way for the user +A window manager which implements a large desktop typically offers a way for the user to make certain windows 'stick to the glass', i.e. these windows will stay at the same position on the screen when the viewport is moved. Virtual Desktops -Most X servers have only a single screen. The Window Manager may virtualize this +Most X servers have only a single screen. The window manager may virtualize this resource and offer multiple so-called 'virtual desktops', of which only one can be shown on the screen at a time. There is some variation among the features of virtual desktop implementations. There may be a fixed number of desktops, or new ones may be created dynamically. The size of the desktops may be fixed or variable. If the desktops are larger than the root window, -their viewports (see ) may be independent or forced to be at the same -position. -A Window Manager which implements virtual desktops generally offers a way for the user +their viewports (see ) may be independent or forced +to be at the same position. +A window manager which implements virtual desktops generally offers a way for the user to move clients between desktops. Clients may be allowed to occupy more than one desktop simultaneously. @@ -167,7 +167,7 @@ window and unmap the frames of those which are not on the current desktop. Unmapped windows should be placed in IconicState, according to the ICCCM. Windows which are actually iconified or minimized should have the _NET_WM_STATE_HIDDEN property set, to -communicate to Pagers that the window should not be represented as +communicate to pagers that the window should not be represented as "onscreen." @@ -176,7 +176,7 @@ communicate to Pagers that the window should not be represented as Pagers A pager offers a different UI for window management tasks. It shows a miniature view of the desktop(s) representing managed windows by small -rectangles and allows the user to initiate various Window Manager actions by manipulating +rectangles and allows the user to initiate various window manager actions by manipulating these representations. Typically offered actions are activation (see ), moving, restacking, iconification, maximization and closing. On a large desktop, the pager may offer a way to move the viewport. On virtual desktops, @@ -187,7 +187,7 @@ current desktop. Taskbars A taskbar offers another UI for window management tasks. It typically represents client windows as a list of buttons labelled with the window -titles and possibly icons. Pressing a button initiates a Window Manager action on the +titles and possibly icons. Pressing a button initiates a window manager action on the represented window, typical actions being activation and iconification. In environments with a taskbar, icons are often considered inappropriate, since the iconified windows are already represented in the taskbar. @@ -202,7 +202,7 @@ is on), deiconifying it or raising it. Animated iconification -Some Window Managers display some form of animation when (de-)iconifying a window. +Some window managers display some form of animation when (de-)iconifying a window. This may be a line drawing connecting the corners of the window with the corners of the icon or the window may be opaquely moved and resized on some trajectory joining the window location and the icon location. @@ -212,14 +212,14 @@ on some trajectory joining the window location and the icon location. Window-in-window MDI is a multiple document interface known from MS Windows platforms. Programs employing it have a single top-level window which contains a workspace which contains the subwindows for the open -documents. These subwindows are decorated with Window Manager frames and can be +documents. These subwindows are decorated with window manager frames and can be manipulated within their parent window just like ordinary top-level windows on the root window. Layered stacking order -Some Window Managers keep the toplevel windows not in a single linear stack, +Some window managers keep the toplevel windows not in a single linear stack, but subdivide the stack into several layers. There is a lot of variation among the features of layered stacking order implementations. The number of layers may or may not be fixed. The layer of a toplevel window may be explicit @@ -234,29 +234,29 @@ layer. This spec tries to address the following issues: Allow clients to influence their initial state with respect -to maximization, shading, stickyness, desktop, stacking order. -Improve the Window Managers ability to vary window +to maximization, shading, stickiness, desktop, stacking order. +Improve the window managers ability to vary window decorations and maintain the stacking order by allowing clients to hint the -Window Manager about the type of their windows. +window manager about the type of their windows. Enable pagers and taskbars to be implemented as separate -clients and allow them to work with any compliant Window Manager. +clients and allow them to work with any compliant window manager. This spec doesn't cover any of the following: Other IPC mechanisms like ICE or Corba. -Window Manager configuration. -Window Manager documentation. +Window manager configuration. +Window manager documentation. Clients appearing on a proper subset of desktops. Window-in-window MDI. -The Window Manager is supposed to be in charge of window management -policy, so that there is consistent behaviour on the user's screen no matter +The window manager is supposed to be in charge of window management +policy, so that there is consistent behavior on the user's screen no matter who wrote the clients. -The spec offers a lot of external control about Window Manager actions. -This is intended mainly to allow pagers, taskbars and similar Window Manager +The spec offers a lot of external control about window manager actions. +This is intended mainly to allow pagers, taskbars and similar window manager UIs to be implemented as separate clients. "Ordinary" clients shouldn't use these except maybe in response to a direct user request (i.e. setting a -config option to start maximized or specifying a -desk n cmdline +config option to start maximized or specifying a -desk n command line argument). @@ -307,7 +307,7 @@ This property SHOULD be set and updated by the Window Manager to indicate the number of virtual desktops. -A Pager can request change in the desktops number by sending a _NET_NUMBER_OF_DESKTOPS message to the root window: +A Pager can request a change in the number of desktops by sending a _NET_NUMBER_OF_DESKTOPS message to the root window: -The Window Manager is free to honor or reject this request. If request is honored _NET_NUMBER_OF_DESKTOPS MUST be set to the new number of desktops, _NET_VIRTUAL_ROOTS MUST be set to store the new number of desktop virtual root window IDs and _NET_DESKTOP_VIEWPORT and _NET_WORKAREA must also be changed accordingly. The _NET_DESKTOP_NAMES property MAY remain unchanged. +The Window Manager is free to honor or reject this request. If the request is honored _NET_NUMBER_OF_DESKTOPS MUST be set to the new number of desktops, _NET_VIRTUAL_ROOTS MUST be set to store the new number of desktop virtual root window IDs and _NET_DESKTOP_VIEWPORT and _NET_WORKAREA must also be changed accordingly. The _NET_DESKTOP_NAMES property MAY remain unchanged. -If the number of desktops is shrinking and _NET_CURRENT_DESKTOP is out of the new range of available desktops, then this MUST be set to the last available desktop from the new set. If number of desktops is shrinking then clients that are still present on desktops, that are out of the new range, MUST be moved to the very last desktop from the new set. For these _NET_WM_DESKTOP MUST be updated. +If the number of desktops is shrinking and _NET_CURRENT_DESKTOP is out of the new range of available desktops, then this MUST be set to the last available desktop from the new set. Clients that are still present on desktops that are out of the new range MUST be moved to the very last desktop from the new set. For these _NET_WM_DESKTOP MUST be updated. @@ -334,7 +334,7 @@ _NET_DESKTOP_GEOMETRY width, height, CARDINAL[2]/32 desktop). This property SHOULD be set by the Window Manager. -A Pager can request a change in the desktop geometry by sending a _NET_DESKTOP_GEOMETRY client +A Pager can request a change in the desktop geometry by sending a _NET_DESKTOP_GEOMETRY client message to the root window: -Array of pairs of cardinals that define the top left corner of each desktops +Array of pairs of cardinals that define the top left corner of each desktop's viewport. For Window Managers that don't support large desktops, this MUST always be set to (0,0). @@ -379,7 +379,7 @@ _NET_CURRENT_DESKTOP desktop, CARDINAL/32 The index of the current desktop. This is always an integer between 0 and _NET_NUMBER_OF_DESKTOPS - 1. This MUST be set and updated by the Window -Manager If a Pager wants to switch to another virtual desktop, it MUST send +Manager. If a Pager wants to switch to another virtual desktop, it MUST send a _NET_CURRENT_DESKTOP client message to the root window: Note: The number of names could be different from _NET_NUMBER_OF_DESKTOPS. -If it is less than _NET_NUMBER_OF_DESKTOPS - then the desktops with high +If it is less than _NET_NUMBER_OF_DESKTOPS, then the desktops with high numbers are unnamed. If it is larger than _NET_NUMBER_OF_DESKTOPS, then the excess names outside of the _NET_NUMBER_OF_DESKTOPS are considered to be -reserved in case number of desktops is increased. +reserved in case the number of desktops is increased. Rationale: The name is not a necessary attribute of a virtual desktop. Thus @@ -418,7 +418,7 @@ _NET_ACTIVE_WINDOW, WINDOW/32 The window ID of the currently active window or None if no window has the focus. This is a read-only property set by the -Window Manager. If a client (for example, a taskbar) wants to activate +Window Manager. If a Client wants to activate another window, it MUST send a _NET_ACTIVE_WINDOW client message to the root window: @@ -435,7 +435,7 @@ _NET_WORKAREA, x, y, width, height CARDINAL[][4]/32 ]]> -This property MUST be set by WM upon calculating the work area for +This property MUST be set by the Window Manager upon calculating the work area for each desktop. Contains a geometry for each desktop. These geometries are specified relative to the viewport on each desktop and specify an area that is completely contained within the viewport. @@ -452,7 +452,7 @@ _NET_SUPPORTING_WM_CHECK, WINDOW/32 ]]> The Window Manager MUST set this property on the root window to be the ID of a - child window created by the WM, to indicate that a compliant WM is + child window created by himself, to indicate that a compliant window manager is active. The child window MUST also have the _NET_SUPPORTING_WM_CHECK property set to the ID of the child window. The child window MUST also have the _NET_WM_NAME property set to the name of the Window Manager. @@ -472,11 +472,11 @@ Rationale: The child window is used to distinguish an active Window Manager _NET_VIRTUAL_ROOTS, WINDOW[]/32 ]]> -To implement virtual desktops, some window managers reparent client windows to -a child of the root window. Window managers using this technique MUST set +To implement virtual desktops, some Window Managers reparent client windows to +a child of the root window. Window Managers using this technique MUST set this property to a list of IDs for windows that are acting as virtual root windows. This property allows background setting programs to work with -virtual roots and allows clients to figure out the WM frame windows of their +virtual roots and allows clients to figure out the window manager frame windows of their windows. @@ -513,7 +513,7 @@ _NET_DESKTOP_LAYOUT, orientation, x, y, starting_corner CARDINAL[4]/32 starting corner of the layout, i.e. the corner containing the first desktop. - Note: In order to interoperate with Pagers implementing an earlier + Note: In order to inter-operate with Pagers implementing an earlier draft of this document, Window Managers should accept a _NET_DESKTOP_LAYOUT property of length 3 and use _NET_WM_TOPLEFT as the starting corner in this case. @@ -529,7 +529,7 @@ _NET_DESKTOP_LAYOUT, orientation, x, y, starting_corner CARDINAL[4]/32 When the orientation is _NET_WM_ORIENTATION_HORZ - the desktops are layed out in rows, with the first desktop in the + the desktops are laid out in rows, with the first desktop in the specified starting corner. So a layout with X=4 and Y=3 starting in the _NET_WM_TOPLEFT corner looks like this: @@ -595,7 +595,7 @@ _NET_SHOWING_DESKTOP desktop, CARDINAL/32 Some Window Managers have a "showing the desktop" mode in which windows are hidden, and the desktop background is displayed and focused. If a Window Manager supports the _NET_SHOWING_DESKTOP hint, it MUST set it - to a value of 1 if the Window Manager is in "showing the desktop" mode, + to a value of 1 when the Window Manager is in "showing the desktop" mode, and a value of zero if the Window Manager is not in this mode. @@ -665,9 +665,9 @@ _NET_MOVERESIZE_WINDOW Window Managers should treat a _NET_MOVERESIZE_WINDOW message exactly - like a ConfigureRequest (in particular, adhere to the ICCCM rules about - synthetic ConfigureNotify events), except that they should use the - gravity specified in the message. + like a ConfigureRequest (in particular, adhering to the ICCCM rules + about synthetic ConfigureNotify events), except that they should use + the gravity specified in the message. Rationale: Using a _NET_MOVERESIZE_WINDOW message with StaticGravity @@ -687,11 +687,11 @@ _NET_WM_MOVERESIZE data.l[3] = button ]]> - This message allows an application to initiate window movement or - resizing. This allows the application to define its own move and size - "grips", whilst letting the window manager control the actual operation. + This message allows Clients to initiate window movement or + resizing. They can define their own move and size + "grips", whilst letting the Window Manager control the actual operation. This means that all moves/resizes can happen in a consistent manner as - defined by the WM. + defined by the Window Manager. When sending this message in response to a button press event, button @@ -700,8 +700,8 @@ _NET_WM_MOVERESIZE window and direction MUST indicate whether this is a move or resize event, and if it is a resize event, which edges of the window the size grip applies to. When sending this message in response to a key event, - the direction MUST indicate wether this this is a move or resize event - and the other fields are unused. + the direction MUST indicate whether this this is a move or resize + event and the other fields are unused. @@ -749,7 +749,7 @@ _NET_WM_VISIBLE_NAME, UTF8_STRING If the Window Manager displays a window name other than _NET_WM_NAME the Window Manager MUST set this to the title displayed in UTF-8 encoding. -Rationale: For window managers that display a title different from the _NET_WM_NAME or WM_NAME of the window (i.e. xterm <1>, xterm <2>, ... is shown, but _NET_WM_NAME / WM_NAME is still xterm for each window). This property allows taskbars / pagers to display the same title as the window manager. +Rationale: This property is for Window Managers that display a title different from the _NET_WM_NAME or WM_NAME of the window (i.e. xterm <1>, xterm <2>, ... is shown, but _NET_WM_NAME / WM_NAME is still xterm for each window) thereby allowing Pagers to display the same title as the Window Manager. @@ -781,8 +781,8 @@ _NET_WM_DESKTOP desktop, CARDINAL/32 Cardinal to determine the desktop the window is in (or wants to be) starting with 0 for the first desktop. A Client MAY choose not to set this property, -in which case the Window Manager SHOULD place as it wishes. 0xFFFFFFFF -indicates that the window SHOULD appear on all desktops/workspaces. +in which case the Window Manager SHOULD place it as it wishes. 0xFFFFFFFF +indicates that the window SHOULD appear on all desktops. The Window Manager should honor _NET_WM_DESKTOP whenever a withdrawn window @@ -790,7 +790,7 @@ requests to be mapped. The Window Manager should remove the property whenever -a window is withdrawn, but it should leave the property in place when it is +a window is withdrawn but it should leave the property in place when it is shutting down, e.g. in response to losing ownership of the WM_Sn manager selection. @@ -819,21 +819,21 @@ _NET_WM_DESKTOP _NET_WM_WINDOW_TYPE, ATOM[]/32 ]]> -This SHOULD be set by the Client before mapping, to a list of atoms indicating +This SHOULD be set by the Client before mapping to a list of atoms indicating the functional type of the window. This property SHOULD be used by the window -manager in determining the decoration, stacking position and other behaviour +manager in determining the decoration, stacking position and other behavior of the window. The Client SHOULD specify window types in order of preference -(the first being most preferable), but MUST include at least one of the basic +(the first being most preferable) but MUST include at least one of the basic window type atoms from the list below. This is to allow for extension of the -list of types, whilst providing default behaviour for window managers that do -not recognise the extensions. +list of types whilst providing default behavior for Window Managers that do +not recognize the extensions. -Rationale: This hint is intend to replace the MOTIF hints. One of the +Rationale: This hint is intended to replace the MOTIF hints. One of the objections to the MOTIF hints is that they are a purely visual description of -the window decoration. By describing the function of the window, the window -manager can apply consistent decoration and behaviour to windows of the same -type. Possible examples of behaviour include keeping dock/panels on top or +the window decoration. By describing the function of the window, the Window +Manager can apply consistent decoration and behavior to windows of the same +type. Possible examples of behavior include keeping dock/panels on top or allowing pinnable menus / toolbars to only be hidden when another window has focus (NextStep style). @@ -855,7 +855,7 @@ the need for proxying root window clicks. _NET_WM_WINDOW_TYPE_DOCK indicates a dock or panel feature. Typically a -window manager would keep such windows on top of all other windows. +Window Manager would keep such windows on top of all other windows. _NET_WM_WINDOW_TYPE_TOOLBAR and _NET_WM_WINDOW_TYPE_MENU indicate toolbar and @@ -882,7 +882,7 @@ be taken as this type. _NET_WM_WINDOW_TYPE_NORMAL indicates that this is a normal, top-level window. -Windows with neither _NET_WM_WINDOW_TYPE nor WM_TRANSIENT_FOR are set MUST +Windows with neither _NET_WM_WINDOW_TYPE nor WM_TRANSIENT_FOR set MUST be taken as this type. @@ -946,7 +946,7 @@ window's position fixed on the screen, even when the virtual desktop scrolls. _NET_WM_STATE_MAXIMIZED_{VERT,HORZ} indicates that the window is -{vertically,horizontally} maximised. +{vertically,horizontally} maximized. _NET_WM_STATE_SHADED indicates that the window is shaded. @@ -967,7 +967,7 @@ Pager. Applications should not set this hint if _NET_WM_WINDOW_TYPE already conveys the exact nature of the window. -_NET_WM_STATE_HIDDEN should be set by the window manager to indicate +_NET_WM_STATE_HIDDEN should be set by the Window Manager to indicate that a window would not be visible on the screen if its desktop/viewport were active and its coordinates were within the screen bounds. The canonical example is that minimized windows should @@ -1011,7 +1011,7 @@ client message to the root window (window is the respective window, type _NET_WM_STATE, format 32, l[0]=<the action, as listed below>, l[1]=<First property to alter>, l[2]=<Second property to alter>). This message allows two properties to be changed simultaneously, specifically -to allow both horizontal and vertical maximisation to be altered together. +to allow both horizontal and vertical maximization to be altered together. l[2] MUST be set to zero if only one property is to be changed. l[0], the action, MUST be one of: @@ -1031,10 +1031,10 @@ _NET_WM_STATE_TOGGLE 2 /* toggle property */ _NET_WM_ALLOWED_ACTIONS, ATOM[] ]]> -A list of atoms indicating user operations that the window manager supports for +A list of atoms indicating user operations that the Window Manager supports for this window. Atoms present in the list indicate allowed actions, atoms not present in the list indicate actions that are not supported for this window. -The window manager MUST keep this property updated to reflect the +The Window Manager MUST keep this property updated to reflect the actions which are currently "active" or "sensitive" for a window. Taskbars, Pagers, and other tools use _NET_WM_ALLOWED_ACTIONS to decide which actions should be made available to the user. @@ -1070,15 +1070,15 @@ _NET_CLOSE_WINDOW message to ask the Window Manager to do so. Window Managers SHOULD ignore the value of _NET_WM_ALLOWED_ACTIONS when they -initially manage a window. This value may be left over from a previous window -manager with different policies. +initially manage a window. This value may be left over from a previous Window +Manager with different policies. _NET_WM_ACTION_MOVE indicates that the window may be moved around the screen. _NET_WM_ACTION_RESIZE indicates that the window may be resized. -(Implementation note: window managers can identify a non-resizable +(Implementation note: Window Managers can identify a non-resizable window because its minimum and maximum size in WM_NORMAL_HINTS will be the same.) @@ -1117,16 +1117,16 @@ _NET_WM_STRUT, left, right, top, bottom, CARDINAL[4]/32 ]]> This property MUST be set by the Client if the window is to reserve space at -the edge of the screen. The property contains a 4 cardinals specifying the +the edge of the screen. The property contains 4 cardinals specifying the width of the reserved area at each border of the screen. The order of the borders is left, right, top, bottom. -The client MAY change this property anytime, therefore the Window Manager MUST +The client MAY change this property at any time, therefore the Window Manager MUST watch out for property notify events. The purpose of struts is to reserve space at the borders of the desktop. This -is very useful for a docking area, a taskbar or a panel, for instance. The -window manager should know about this reserved space in order to be able to +is very useful for a docking area, a taskbar or a panel, for instance. The +Window Manager should know about this reserved space in order to be able to preserve the space. Also maximized windows should not cover that reserved space. @@ -1144,11 +1144,11 @@ SHOULD only set one strut. _NET_WM_ICON_GEOMETRY, x, y, width, height, CARDINAL[4]/32 ]]> -This optional property MAY be set by standalone tools like a taskbar or an +This optional property MAY be set by stand alone tools like a taskbar or an iconbox. It specifies the geometry of a possible icon in case the window is iconified. -Rationale: This makes it possible for a window manager to display a nice +Rationale: This makes it possible for a Window Manager to display a nice animation like morphing the window into its icon. @@ -1165,7 +1165,7 @@ icons to an appropriate size. This is an array of 32bit packed CARDINAL ARGB with high byte being A, low -byte being B. First two cardinals are width, height. Data is in rows, left to +byte being B. The first two cardinals are width, height. Data is in rows, left to right and top to bottom. @@ -1211,7 +1211,7 @@ _NET_WM_HANDLED_ICONS This protocol allows the Window Manager to determine if the Client is still processing X events. This can be used by the Window Manager to determine if a window which fails to close after being sent WM_DELETE_WINDOW has stopped -responding, or has stalled for some other reason, such as waiting for user +responding or has stalled for some other reason, such as waiting for user confirmation. A Client SHOULD indicate that it is willing to participate in this protocol by listing _NET_WM_PING in the WM_PROTOCOLS property of the client window. @@ -1250,7 +1250,7 @@ See also the implementation notes on killing hung 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 +When a desktop is larger than the screen it is left to the Window Manager if it will implement scrolling or paging. @@ -1271,7 +1271,7 @@ in applications that want to draw the background (xearth). 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 +has been noted that this is a slight ICCCM violation, but as this behavior is pretty standard for many toolkits and window managers, and is extremely unlikely to break anything, it seems reasonable to document it as standard. @@ -1291,7 +1291,12 @@ unlikely to break anything, it seems reasonable to document it as standard. 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. + This specification attempts to make reasonable provisions for window + manager 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 communicate with the Window Manager using further, + window manager specific hints, or some other means. Pagers should decide whether to show a miniature version of a @@ -1316,17 +1321,17 @@ unlikely to break anything, it seems reasonable to document it as standard. If the _NET_WM_STATE_SKIP_PAGER and _NET_WM_STATE_HIDDEN hints are not present, and the - window manager claims to support _NET_WM_STATE_HIDDEN, + Window Manager claims to support _NET_WM_STATE_HIDDEN, then the window should be shown if it's in either NormalState or IconicState. - For window managers that do not support + For Window Managers that do not support _NET_WM_STATE_HIDDEN, the pager should - not show windows in IconicState. These window - managers are probably using an older version + not show windows in IconicState. These Window + Managers are probably using an older version of this specification. @@ -1343,17 +1348,17 @@ document offers the following clarifications: -Window managers MUST honour the win_gravity field of WM_NORMAL_HINTS +Window managers MUST honor the win_gravity field of WM_NORMAL_HINTS for both MapRequest _and_ ConfigureRequest events (ICCCM Version 2.0, §4.1.2.3 and §4.1.5) -Applications are free to change their win_gravity setting at any time +Applications are free to change their win_gravity setting at any time. -If application changes its gravity then Window manager should adjust the -reference point, so that client window will not move as the result. -For example if client's gravity was NorthWestGravity and reference point +If an application changes its gravity then the Window Manager should adjust the +reference point, so that the client window will not move as the result. +For example if Client's gravity was NorthWestGravity and reference point was at the top-left corner of the frame window, then after change of gravity to the SouthEast reference point should be adjusted to point to the @@ -1366,10 +1371,10 @@ When generating synthetic ConfigureNotify events, the position given origin of the root window (i.e., ignoring win_gravity) (ICCCM Version 2.0, §4.2.3) -XMoveWindow(w,x,y) behaviour depends on the window gravity. Upon receiving a -request from client application the Window Manager calculates a new reference -point, based on the client window's own size, border width and gravity. For given client -window dimentions (width, height) and border width (bw), the reference point will be +XMoveWindow(w,x,y) behavior depends on the window gravity. Upon receiving a +request from a client application the Window Manager calculates a new reference +point, based on the client window's own size, border width and gravity. +For any given client window dimensions (width, height) and border width (bw), the reference point will be placed at: @@ -1435,8 +1440,8 @@ placed at: -The Window manager will use the reference point as calculated above, -until next XMoveWindow request. The Window Manager will place frame decorations +The Window Manager will use the reference point as calculated above, +until the next XMoveWindow request. The Window Manager will place frame decorations in the following position, based on the window gravity : @@ -1504,17 +1509,17 @@ window frame's center will be placed at (ref_x,ref_y) Implementation Note for Application developers: -When client window is resized - its reference point does not move. +When a client window is resized - its reference point does not move. So for example if window has SouthEastGravity and it is resized - the bottom-right corner of its frame will not move but instead top-left corner will be adjusted by the difference in size. -Implementation Note for WM developers : +Implementation Note for window manager developers: -when calculating reference point at the time of initial placement - -initial window's width should be taken into consideration, as if it +When calculating the reference point at the time of initial placement - +the initial window's width should be taken into consideration, as if it was the frame for this window. @@ -1597,8 +1602,9 @@ int net_get_hostname (char *buf, size_t maxlen) The window manager may choose to put some windows in different - stacking position, for example to allow user to bring currently active - window to the top and return it back when the window looses focus. + stacking positions, for example to allow the user to bring currently + a active window to the top and return it back when the window looses + focus. @@ -1904,7 +1910,7 @@ fixed formatting of _NET_CLOSE_WINDOW message. Changes since 1.0pre1 -Removed implementation note concerning Gnome's (potential) file manager behaviour. +Removed implementation note concerning Gnome's (potential) file manager behavior. The Window Movement section of the implementation notes has been revised. -- cgit v1.2.3-54-g00ecf From 4a1011a4b202e800c04b08a6919c23531bf4988c Mon Sep 17 00:00:00 2001 From: matthiasc Date: Wed, 27 Nov 2002 19:23:24 +0000 Subject: Rewrote some implementation notes for more clarity. --- wm-spec/wm-spec.sgml | 228 +++++++++++++++++++++++++++------------------------ 1 file changed, 122 insertions(+), 106 deletions(-) diff --git a/wm-spec/wm-spec.sgml b/wm-spec/wm-spec.sgml index 8f54a80..f3e46cf 100644 --- a/wm-spec/wm-spec.sgml +++ b/wm-spec/wm-spec.sgml @@ -1,6 +1,6 @@ - + + ]>
@@ -1279,7 +1279,8 @@ unlikely to break anything, it seems reasonable to document it as standard. 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. +Windows expecting immediate user action should indicate this using the +urgency bit in the WM_HINTS.flags property, as defined in the ICCCM. @@ -1339,7 +1340,7 @@ unlikely to break anything, it seems reasonable to document it as standard. - Window Movement + Window Geometry Window manager implementors should refer to the ICCCM for definitive specifications of how to handle MapRequest and ConfigureRequest events. @@ -1348,40 +1349,114 @@ document offers the following clarifications: -Window managers MUST honor the win_gravity field of WM_NORMAL_HINTS - for both MapRequest _and_ ConfigureRequest events (ICCCM Version 2.0, - §4.1.2.3 and §4.1.5) +Window Managers MUST honor the win_gravity field of WM_NORMAL_HINTS +for both MapRequest and ConfigureRequest events +(ICCCM Version 2.0, §4.1.2.3 and §4.1.5) +When generating synthetic ConfigureNotify events, the position given +MUST be the top-left corner of the client window in relation to the +origin of the root window (i.e., ignoring win_gravity) +(ICCCM Version 2.0, §4.2.3) + + +Window Managers maintain a reference point for each client window and place +the window relative to this reference point depending on the window's +win_gravity as follows: + + + + + + win_gravity: + placed at the reference point + + + StaticGravity + the left top corner of the client window + + + NorthWestGravity + the left top corner of the frame window + + + NorthGravity + the center of the frame window's top side + + + NorthEastGravity + the right top corner of the frame window + + + EastGravity + the center of the frame window's right side + + + SouthEastGravity + the right bottom corner of the frame window + + + SouthGravity + the center of the frame window's bottom side + + + SouthWestGravity + the left bottom corner of the frame window + + + WestGravity + the center of the frame window's left side + + + CenterGravity + the center of the frame window + + + + + + Applications are free to change their win_gravity setting at any time. -If an application changes its gravity then the Window Manager should adjust the -reference point, so that the client window will not move as the result. -For example if Client's gravity was NorthWestGravity and reference point -was -at the top-left corner of the frame window, then after change of gravity to -the SouthEast reference point should be adjusted to point to the -lower-right -corner of the frame. - - -When generating synthetic ConfigureNotify events, the position given - MUST be the top-left corner of the client window in relation to the - origin of the root window (i.e., ignoring win_gravity) (ICCCM Version 2.0, §4.2.3) - +If an Application changes its win_gravity then the Window Manager should +adjust the reference point, so that the client window will not move as the +result. For example if the Application's win_gravity was NorthWestGravity and +reference point was at the top-left corner of the frame window, then after +change of win_gravity to SouthEastGravity the reference point should be +adjusted to point to the lower-right corner of the frame. + + + +Changing the win_gravity for a single configure request and back afterwards is +unlikely to work as intended, due to a race condition. The window manager sees +a property notify for WM_NORMAL_HINTS, followed by the configure request, +followed by another property notify for WM_NORMAL_HINTS. By the time the +window manager gets around to request the changed WM_NORMAL_HINTS in response +to the first property notify, the server may have already processed the second +property change. + + +If the window manager supports it, applications should use +_NET_MOVERESIZE_WINDOW with a specified gravity to avoid this problem. + + + -XMoveWindow(w,x,y) behavior depends on the window gravity. Upon receiving a -request from a client application the Window Manager calculates a new reference -point, based on the client window's own size, border width and gravity. -For any given client window dimensions (width, height) and border width (bw), the reference point will be -placed at: +If the Application requests a new position (x, y) (and possibly also a +new size), the Window Manager calculates a new reference point (ref_x, ref_y), +based on the client window's (possibly new) size (width, height), border +width (bw) and win_gravity as explained in the table below. + + +The Window Manager will use the new reference point until the next request for +a new position. - Gravity: + win_gravity: ref_x: ref_y: @@ -1437,90 +1512,18 @@ placed at: - - -The Window Manager will use the reference point as calculated above, -until the next XMoveWindow request. The Window Manager will place frame decorations -in the following position, based on the window gravity : - - -StaticGravity: - - -window's left top corner will be placed at (ref_x,ref_y) - - -NorthWestGravity: - - -window frame's left top corner will be placed at (ref_x,ref_y) - - -NorthGravity: - - -window frame's top side's center will be placed at (ref_x,ref_y) - - -NorthEastGravity: - - -window frame's right top corner will be placed at (ref_x,ref_y) - - -EastGravity: - - -window frame's right side's center will be placed at (ref_x,ref_y) - - -SouthWestGravity: - - -window frame's left bottom corner will be placed at (ref_x,ref_y) - - -SouthGravity: - - -window frame's bottom side's center will be placed at (ref_x,ref_y) - - -SouthEastGravity: - - -window frame's right bottom corner will be placed at (ref_x,ref_y) - - -WestGravity: - - -window frame's left side's center will be placed at (ref_x,ref_y) - - -CenterGravity: - - -window frame's center will be placed at (ref_x,ref_y) - -Implementation Note for Application developers: - - -When a client window is resized - its reference point does not move. -So for example if window has SouthEastGravity and it is resized - -the bottom-right corner of its frame will not move but instead -top-left corner will be adjusted by the difference in size. +If an Application requests just a new size, its reference point does not +move. So for example if client window has win_gravity SouthEastGravity and +is resized, the bottom right corner of its frame will not move but instead +the top left corner will be adjusted by the difference in size. -Implementation Note for window manager developers: - - -When calculating the reference point at the time of initial placement - -the initial window's width should be taken into consideration, as if it -was the frame for this window. +When calculating the reference point at the time of initial placement, +the Window Manager should take the initial window's size into consideration, +as if it was the frame for this window. @@ -1690,6 +1693,19 @@ OR OTHER DEALINGS IN THE SOFTWARE. Change history + + Changes since 1.2 + + +Rewrote the implementation notes on "Window Movement", retitled it +to "Window Geometry". + + +Rewrote the implementation notes on "Urgency", making it clear that +the hint is not just about dialogs. + + + Changes since 1.1 -- cgit v1.2.3-54-g00ecf From 2ab0ee8ad15d9b46da9d78a307ef5552197db65d Mon Sep 17 00:00:00 2001 From: matthiasc Date: Fri, 3 Jan 2003 20:29:28 +0000 Subject: New draft. --- wm-spec/wm-spec.sgml | 50 +++++++++++++++++++++++++++++++------------------- 1 file changed, 31 insertions(+), 19 deletions(-) diff --git a/wm-spec/wm-spec.sgml b/wm-spec/wm-spec.sgml index f3e46cf..400ca69 100644 --- a/wm-spec/wm-spec.sgml +++ b/wm-spec/wm-spec.sgml @@ -1,6 +1,6 @@ - + ]>
@@ -18,7 +18,11 @@ Version -This is &version; of the Extended Window Manager Hints (EWMH) spec, updated &date;. +This is &version; of the Extended Window Manager Hints (EWMH) spec, updated +&date;. The canonical home for this document is http://www.freedesktop.org, +which also contains directions for reporting bugs or contributing to future +versions. @@ -483,7 +487,7 @@ windows. _NET_DESKTOP_LAYOUT #define _NET_WM_ORIENTATION_HORZ 0 #define _NET_WM_ORIENTATION_VERT 1 @@ -519,19 +523,20 @@ _NET_DESKTOP_LAYOUT, orientation, x, y, starting_corner CARDINAL[4]/32 use _NET_WM_TOPLEFT as the starting corner in this case. - The virtual desktops are arranged in a rectangle - with X rows and Y columns. If X times Y does not match the total number of - desktops as specified by + The virtual desktops are arranged in a rectangle with + rows rows and columns columns. + If rows times columns does not match + the total number of desktops as specified by _NET_NUMBER_OF_DESKTOPS, the highest-numbered - workspaces are assumed to be nonexistent. Either X or Y (but not - both) may be specified as 0 in which case its actual value will be - derived from _NET_NUMBER_OF_DESKTOPS. + workspaces are assumed to be nonexistent. Either rows or + columns (but not both) may be specified as 0 in which + case its actual value will be derived from _NET_NUMBER_OF_DESKTOPS. When the orientation is _NET_WM_ORIENTATION_HORZ the desktops are laid out in rows, with the first desktop in the - specified starting corner. So a layout with X=4 and Y=3 starting in - the _NET_WM_TOPLEFT corner looks like this: + specified starting corner. So a layout with four columns and three rows + starting in the _NET_WM_TOPLEFT corner looks like this: +--+--+--+--+ | 0| 1| 2| 3| @@ -541,8 +546,7 @@ _NET_DESKTOP_LAYOUT, orientation, x, y, starting_corner CARDINAL[4]/32 | 8| 9|10|11| +--+--+--+--+ -With starting_corner _NET_WM_BOTTOMRIGHT, it looks like -this: +With starting_corner _NET_WM_BOTTOMRIGHT, it looks like this: +--+--+--+--+ |11|10| 9| 8| @@ -555,9 +559,8 @@ this: - When the orientation is _NET_WM_ORIENTATION_VERT - the layout for X=4 and Y=3 starting in the _NET_WM_TOPLEFT + the layout with four columns and three rows starting in the _NET_WM_TOPLEFT corner looks like: @@ -935,10 +938,10 @@ them from the list. These extension atoms MUST NOT start with the prefix _NET. -_NET_WM_STATE_MODAL indicates that this is a modal dialog box. The -WM_TRANSIENT_FOR hint MUST be set to indicate which window the dialog is a -modal for, or set to the root window if the dialog is a modal for its window -group. +_NET_WM_STATE_MODAL indicates that this is a modal dialog box. +If the WM_TRANSIENT_FOR hint is set to another toplevel window, the +dialog is modal for that window; if WM_TRANSIENT_FOR is not set or set +to the root window the dialog is modal for its window group. _NET_WM_STATE_STICKY indicates that the Window Manager SHOULD keep the @@ -1704,6 +1707,15 @@ to "Window Geometry". Rewrote the implementation notes on "Urgency", making it clear that the hint is not just about dialogs. + +Fixed the specification of the X and Y members of _NET_DESKTOP_LAYOUT +and renamed them to columns and row for clarity. + + +Change the description of _NET_WM_STATE_MODAL to no longer require apps to +break the ICCCM for group-modal windows, but still support the +WM_TRANSIENT_FOR=root dialect. + -- cgit v1.2.3-54-g00ecf From 81e304e252c8d5d8487354932fbc85a90bbe4fa1 Mon Sep 17 00:00:00 2001 From: hp Date: Sun, 29 Jun 2003 22:18:19 +0000 Subject: add _NET_WM_STRUT_PARTIAL --- wm-spec/wm-spec.sgml | 85 ++++++++++++++++++++++++++++++++++++++++++---------- 1 file changed, 70 insertions(+), 15 deletions(-) diff --git a/wm-spec/wm-spec.sgml b/wm-spec/wm-spec.sgml index 400ca69..9cfddd5 100644 --- a/wm-spec/wm-spec.sgml +++ b/wm-spec/wm-spec.sgml @@ -1,6 +1,6 @@ - + ]>
@@ -446,7 +446,11 @@ completely contained within the viewport. Work area SHOULD be used by desktop applications to place desktop icons appropriately. - The Window Manager SHOULD calculate this space by taking the current page minus space occupied by dock and panel windows, as indicated by the _NET_WM_STRUT property set on client windows. +The Window Manager SHOULD calculate this space by taking the current +page minus space occupied by dock and panel windows, as indicated by +the _NET_WM_STRUT or _NET_WM_STRUT_PARTIAL properties set on +client windows. @@ -1119,19 +1123,65 @@ message may be sent). _NET_WM_STRUT, left, right, top, bottom, CARDINAL[4]/32 ]]> -This property MUST be set by the Client if the window is to reserve space at -the edge of the screen. The property contains 4 cardinals specifying the -width of the reserved area at each border of the screen. -The order of the borders is left, right, top, bottom. -The client MAY change this property at any time, therefore the Window Manager MUST -watch out for property notify events. +This property is equivalent to a _NET_WM_STRUT_PARTIAL property where all start +values are 0 and all end values are the height or width of the logical screen. +_NET_WM_STRUT_PARTIAL was introduced later than _NET_WM_STRUT, however, so +clients MAY set this property in addition to _NET_WM_STRUT_PARTIAL to ensure +backward compatibility with Window Managers supporting older versions of the +Specification. + + +_NET_WM_STRUT_PARTIAL + + +This property MUST be set by the Client if the window is to reserve space at the +edge of the screen. The property contains 4 cardinals specifying the width of +the reserved area at each border of the screen, and an additional 8 cardinals +specifying the beginning and end corresponding to each of the four struts. The +order of the values is left, right, top, bottom, left_start_y, left_end_y, +right_start_y, right_end_y, top_start_x, top_end_x, bottom_start_x, +bottom_end_x. All coordinates are root window coordinates. The client MAY change +this property at any time, therefore the Window Manager MUST watch for +property notify events if the Window Manager uses this property to assign +special semantics to the window. -The purpose of struts is to reserve space at the borders of the desktop. This -is very useful for a docking area, a taskbar or a panel, for instance. The -Window Manager should know about this reserved space in order to be able to -preserve the space. Also maximized windows should not cover that reserved -space. +If both this property and the _NET_WM_STRUT property are set, the Window Manager +MUST ignore the _NET_WM_STRUT property values and use instead the values for +_NET_WM_STRUT_PARTIAL. This will ensure that Clients can safely set both +properties without giving up the improved semantics of the new property. + + +The purpose of struts is to reserve space at the borders of the +desktop. This is very useful for a docking area, a taskbar or a panel, +for instance. The Window Manager should take this reserved area into +account when constraining window positions - maximized windows, for +example, should not cover that area. + + +The start and end values associated with each strut allow areas to be +reserved which do not span the entire width or height of the screen. +Struts MUST be specified in root window coordinates, that is, they are +not relative to the edges of any view port or Xinerama +monitor. + + +For example, for a panel-style Client appearing at the bottom of the +screen, 50 pixels tall, and occupying the space from 200-600 pixels +from the left of the screen edge would set a bottom strut of 50, and +set bottom_start_x to 200 and bottom_end_x to 600. Another example is +a panel on a screen using the Xinerama extension. Assume that the set +up uses two monitors, one running at 1280x1024 and the other to the +right running at 1024x768, with the top edge of the two physical +displays aligned. If the panel wants to fill the entire bottom edge +of the smaller display with a panel 50 pixels tall, it should set a +bottom strut of 306, with bottom_start_x of 1280, and bottom_end_x of +2303. Note that the strut is relative to the screen edge, and not the +edge of the xinerama monitor. Rationale: A simple "do not cover" hint is not enough for dealing with e.g. @@ -1142,7 +1192,8 @@ Notes: An auto-hide panel SHOULD set the strut to be its minimum, hidden size. A "corner" panel that does not extend for the full length of a screen border SHOULD only set one strut. - _NET_WM_ICON_GEOMETRY + +_NET_WM_ICON_GEOMETRY @@ -1640,7 +1691,7 @@ int net_get_hostname (char *buf, size_t maxlen) Copyright -Copyright (C) 2000, 2001, 2002 See Contributors List +Copyright (C) 2000-2003 See Contributors List Permission is hereby granted, free of charge, to any person @@ -1693,6 +1744,7 @@ OR OTHER DEALINGS IN THE SOFTWARE. Matthias Clasen David Rosenthal Lubos Lunak + Rob Adams Change history @@ -1700,6 +1752,9 @@ OR OTHER DEALINGS IN THE SOFTWARE. Changes since 1.2 +Added new property _NET_WM_STRUT_PARTIAL to allow partial-width struts. + + Rewrote the implementation notes on "Window Movement", retitled it to "Window Geometry". -- cgit v1.2.3-54-g00ecf From 0ebd2485eea7d0704a2030becc4644fd7437bbc8 Mon Sep 17 00:00:00 2001 From: lanius Date: Wed, 9 Jul 2003 13:50:06 +0000 Subject: changed from sgml to xml --- wm-spec/wm-spec.dsl | 44 -- wm-spec/wm-spec.sgml | 2153 -------------------------------------------------- wm-spec/wm-spec.xml | 2153 ++++++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 2153 insertions(+), 2197 deletions(-) delete mode 100644 wm-spec/wm-spec.dsl delete mode 100644 wm-spec/wm-spec.sgml create mode 100644 wm-spec/wm-spec.xml diff --git a/wm-spec/wm-spec.dsl b/wm-spec/wm-spec.dsl deleted file mode 100644 index a4b5f6c..0000000 --- a/wm-spec/wm-spec.dsl +++ /dev/null @@ -1,44 +0,0 @@ - - -]> - - - -;; html customization goes here - -(define %root-filename% "index") -(define %html-ext% ".html") - - - - - - -;; print customization goes here - - - - - -;; common customization goes here - -(define %section-autolabel% #t) -(define %quanda-inherit-numeration% #t) -(define %generate-article-toc% #t) -(define (article-titlepage-recto-elements) - (list (normalize "title") - (normalize "subtitle") - (normalize "corpauthor") - (normalize "authorgroup") - (normalize "author") - (normalize "releaseinfo") - (normalize "date"))) - - - - - - - - diff --git a/wm-spec/wm-spec.sgml b/wm-spec/wm-spec.sgml deleted file mode 100644 index 9cfddd5..0000000 --- a/wm-spec/wm-spec.sgml +++ /dev/null @@ -1,2153 +0,0 @@ - - -]> -
- - - - X Desktop Group - - -Extended Window Manager Hints -&date; -&version; - - - Introduction - - Version - -This is &version; of the Extended Window Manager Hints (EWMH) spec, updated -&date;. The canonical home for this document is http://www.freedesktop.org, -which also contains directions for reporting bugs or contributing to future -versions. - - - - What is this spec? - -This spec defines interactions between window managers, applications, -and the utilities that form part of a desktop environment. It builds -on the Inter-Client Communication Conventions Manual ICCCM, which defines -window manager interactions at a lower level. The ICCCM does not provide ways -to implement many features that modern desktop users expect. The GNOME and KDE -desktop projects originally developed their own extensions to the ICCCM to -support these features; this spec replaces those custom extensions -with a standardized set of ICCCM additions that any desktop -environment can adopt. - - - - Language used in this specification - -The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", -"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be -interpreted as described in RFC 2119. - - -The key words "Window Manager" refer to a window manager which is adopting this -specification. "Pager" refers to desktop utility applications, including -pagers and taskbars. "Application" refers to other clients. "Clients" refers -to Pagers and Applications ie. all X clients, except for the Window Manager. - - - - Prerequisites for adoption of this specification - -Window Managers and Clients which aim to fulfill this specification MUST adhere -to the ICCCM on which this specification builds. If this specification -explicitly modifies the ICCCM Window Managers and Clients MUST fulfill these -modifications. - - - - -Non-ICCCM features -There is a number of window management features or behaviors which are -not specified in the ICCCM, but are commonly met in modern window managers and desktop environments. - -Additional States -The ICCCM allows window managers to implement additional window states, which will -appear to clients as substates of NormalState and IconicState. Two -commonly met examples are Maximized and Shaded. A window manager may implement these -as proper substates of NormalState and IconicState, or it may treat them -as independent flags, allowing e.g. a maximized window to be iconified -and to re-appear as maximized upon de-iconification. - -Maximization -Maximization is a very old feature of window managers. There was even a ZoomedState -in early ICCCM drafts. Maximizing a window should give it as much of the -screen area as possible (this may not be the full screen area, but only -a smaller 'workarea', since the window manager may have reserved certain areas for other -windows). A window manager is expected to remember the geometry of a maximized window -and restore it upon de-maximization. Modern window managers typically allow separate -horizontal and vertical maximization. -With the introduction of the Xinerama extension in X11 R6.4, maximization -has become more involved. Xinerama allows a screen to span multiple -monitors in a freely configurable geometry. In such a setting, maximizing -a window would ideally not grow it to fill the whole screen, but only the -monitor it is shown on. There are of course borderline cases for windows -crossing monitor boundaries, and 'real' maximization to the full screen may -sometimes be useful. - - -Shading -Some desktop environments offer shading (also known as rollup) as an alternative to -iconification. A shaded window typically shows only the titlebar, the client -window is hidden, thus shading is not useful for windows which are not -decorated with a titlebar. - - - -Modality -The WM_TRANSIENT_FOR hint of the ICCCM allows clients to specify that a -toplevel window may be closed before the client finishes. A typical example -of a transient window is a dialog. Some dialogs can be open for a long time, -while the user continues to work in the main window. Other dialogs have to be -closed before the user can continue to work in the main window. This property -is called modality. While clients can implement modal windows in an ICCCM -compliant way using the globally active input model, some window managers offer support -for handling modality. - - - -Large Desktops -The window manager may offer to arrange the managed windows on a desktop that is -larger than the root window. The screen functions as a viewport on this large -desktop. Different policies regarding the positioning of the viewport on the -desktop can be implemented: The window manager may only allow the viewport -position to change in increments of the screen size (paging) or it may allow -arbitrary positions (scrolling). -To fulfill the ICCCM principle that clients should behave the same -regardless whether a window manager is running or not, window managers which -implement large desktops must interpret all client-provided geometries with -respect to the current viewport. - -Implementation note -There are two options for implementing a large desktop: The first is to -keep the managed windows (or, if reparenting, their frames) as children -of the root window. Moving the viewport is achieved by moving all managed -windows in the opposite direction. -The second alternative is to reparent all managed windows to a dedicated -large window (somewhat inappropriately called a 'virtual root'). Moving -the viewport is then achieved by moving the virtual root in the opposite -direction. -Both alternatives are completely ICCCM compliant, although the second one -may be somewhat problematic for clients trying to figure out the window manager decorations -around their toplevel windows and for clients trying to draw background -images on the root window. - - - -Sticky windows -A window manager which implements a large desktop typically offers a way for the user -to make certain windows 'stick to the glass', i.e. these windows will stay -at the same position on the screen when the viewport is moved. - - -Virtual Desktops -Most X servers have only a single screen. The window manager may virtualize this -resource and offer multiple so-called 'virtual desktops', of which only one -can be shown on the screen at a time. There is some variation among the -features of virtual desktop implementations. There may be a fixed number -of desktops, or new ones may be created dynamically. The size of the desktops -may be fixed or variable. If the desktops are larger than the root window, -their viewports (see ) may be independent or forced -to be at the same position. -A window manager which implements virtual desktops generally offers a way for the user -to move clients between desktops. Clients may be allowed to occupy more than -one desktop simultaneously. - -Implementation note -There are at least two options for implementing virtual desktops. -The first is to use multiple virtual roots (see ) and change the current -desktop by manipulating the stacking order of the virtual roots. This is -completely ICCCM compliant, but has the issues outlined in -The second option is to keep all managed windows as children of the root -window and unmap the frames of those which are not on the current -desktop. Unmapped windows should be placed in IconicState, according to -the ICCCM. Windows which are actually iconified or minimized -should have the _NET_WM_STATE_HIDDEN property set, to -communicate to pagers that the window should not be represented as -"onscreen." - - - - -Pagers -A pager offers a different UI for window management tasks. It shows a -miniature view of the desktop(s) representing managed windows by small -rectangles and allows the user to initiate various window manager actions by manipulating -these representations. Typically offered actions are activation (see ), -moving, restacking, iconification, maximization and closing. On a large -desktop, the pager may offer a way to move the viewport. On virtual desktops, -the pager may offer ways to move windows between desktops and to change the -current desktop. - - -Taskbars -A taskbar offers another UI for window management tasks. It typically -represents client windows as a list of buttons labelled with the window -titles and possibly icons. Pressing a button initiates a window manager action on the -represented window, typical actions being activation and iconification. -In environments with a taskbar, icons are often considered inappropriate, -since the iconified windows are already represented in the taskbar. - - -Activation -In the X world, activating a window means to give it the input focus. -This may not be possible if the window is unmapped, because it is on a -different desktop. Thus, activating a window may involve additional steps -like moving it to the current desktop (or changing to the desktop the window -is on), deiconifying it or raising it. - - -Animated iconification -Some window managers display some form of animation when (de-)iconifying a window. -This may be a line drawing connecting the corners of the window with -the corners of the icon or the window may be opaquely moved and resized -on some trajectory joining the window location and the icon location. - - -Window-in-window MDI -Window-in-window MDI is a multiple document interface known from MS -Windows platforms. Programs employing it have a single top-level window -which contains a workspace which contains the subwindows for the open -documents. These subwindows are decorated with window manager frames and can be -manipulated within their parent window just like ordinary top-level -windows on the root window. - - -Layered stacking order - -Some window managers keep the toplevel windows not in a single linear stack, -but subdivide the stack into several layers. There is a lot of variation -among the features of layered stacking order implementations. The number of -layers may or may not be fixed. The layer of a toplevel window may be explicit -and directly modifiable or derived from other properties of the window, e.g. -the type of the window. The stacking order may or may not -be strict, i.e. not allow the user to raise or lower windows beyond their -layer. - - - -Scope of this spec -This spec tries to address the following issues: - -Allow clients to influence their initial state with respect -to maximization, shading, stickiness, desktop, stacking order. -Improve the window managers ability to vary window -decorations and maintain the stacking order by allowing clients to hint the -window manager about the type of their windows. -Enable pagers and taskbars to be implemented as separate -clients and allow them to work with any compliant window manager. - -This spec doesn't cover any of the following: - -Other IPC mechanisms like ICE or Corba. -Window manager configuration. -Window manager documentation. -Clients appearing on a proper subset of desktops. -Window-in-window MDI. - -The window manager is supposed to be in charge of window management -policy, so that there is consistent behavior on the user's screen no matter -who wrote the clients. -The spec offers a lot of external control about window manager actions. -This is intended mainly to allow pagers, taskbars and similar window manager -UIs to be implemented as separate clients. "Ordinary" clients shouldn't use -these except maybe in response to a direct user request (i.e. setting a -config option to start maximized or specifying a -desk n command line -argument). - - - - Root Window Properties (and Related Messages) - -Whenever this spec speaks about sending a message to the root -window, it is understood that the client is supposed to create -a ClientMessage event with the specified contents and send it by using -a SendEvent request with the following arguments: - - - _NET_SUPPORTED - - -This property MUST be set by the Window Manager to indicate which hints it -supports. For example: considering _NET_WM_STATE -both this atom and all supported states e.g. _NET_WM_STATE_MODAL, -_NET_WM_STATE_STICKY, would be listed. This assumes that backwards -incompatible changes will not be made to the hints (without being renamed). - - _NET_CLIENT_LIST - - -These arrays contain all X Windows managed by the Window Manager. -_NET_CLIENT_LIST has initial mapping order, starting with the oldest window. -_NET_CLIENT_LIST_STACKING has bottom-to-top stacking order. These properties -SHOULD be set and updated by the Window Manager. - - - - _NET_NUMBER_OF_DESKTOPS - - -This property SHOULD be set and updated by the Window Manager to indicate the -number of virtual desktops. - - -A Pager can request a change in the number of desktops by sending a _NET_NUMBER_OF_DESKTOPS message to the root window: - - - -The Window Manager is free to honor or reject this request. If the request is honored _NET_NUMBER_OF_DESKTOPS MUST be set to the new number of desktops, _NET_VIRTUAL_ROOTS MUST be set to store the new number of desktop virtual root window IDs and _NET_DESKTOP_VIEWPORT and _NET_WORKAREA must also be changed accordingly. The _NET_DESKTOP_NAMES property MAY remain unchanged. - - -If the number of desktops is shrinking and _NET_CURRENT_DESKTOP is out of the new range of available desktops, then this MUST be set to the last available desktop from the new set. Clients that are still present on desktops that are out of the new range MUST be moved to the very last desktop from the new set. For these _NET_WM_DESKTOP MUST be updated. - - - - _NET_DESKTOP_GEOMETRY - - - Array of two cardinals that defines the common size of all desktops - (this is equal to the screen size if the Window Manager doesn't support - large desktops, otherwise it's equal to the virtual size of the - desktop). This property SHOULD be set by the Window Manager. - - -A Pager can request a change in the desktop geometry by sending a _NET_DESKTOP_GEOMETRY client -message to the root window: - - - -The Window Manager MAY choose to ignore this message, in which case _NET_DESKTOP_GEOMETRY property will remain unchanged. - - - - _NET_DESKTOP_VIEWPORT - - -Array of pairs of cardinals that define the top left corner of each desktop's -viewport. For Window Managers that don't support large desktops, this MUST -always be set to (0,0). - - -A Pager can request to change the viewport for the current desktop by sending a -_NET_DESKTOP_VIEWPORT client message to the root window: - - - -The Window Manager MAY choose to ignore this message, in which case _NET_DESKTOP_VIEWPORT property will remain unchanged. - - _NET_CURRENT_DESKTOP - - -The index of the current desktop. This is always an integer between 0 and -_NET_NUMBER_OF_DESKTOPS - 1. This MUST be set and updated by the Window -Manager. If a Pager wants to switch to another virtual desktop, it MUST send -a _NET_CURRENT_DESKTOP client message to the root window: - - - _NET_DESKTOP_NAMES - - -The names of all virtual desktops. This is a list of NULL-terminated strings in - UTF-8 encoding UTF8. This property MAY be - changed by a Pager or the Window Manager at any time. - - -Note: The number of names could be different from _NET_NUMBER_OF_DESKTOPS. -If it is less than _NET_NUMBER_OF_DESKTOPS, then the desktops with high -numbers are unnamed. If it is larger than _NET_NUMBER_OF_DESKTOPS, then the -excess names outside of the _NET_NUMBER_OF_DESKTOPS are considered to be -reserved in case the number of desktops is increased. - - -Rationale: The name is not a necessary attribute of a virtual desktop. Thus -the availability or unavailability of names has no impact on virtual desktop -functionality. Since names are set by users and users are likely to preset -names for a fixed number of desktops, it doesn't make sense to shrink or grow -this list when the number of available desktops changes. - - _NET_ACTIVE_WINDOW - - -The window ID of the currently active window or None if no window has the focus. -This is a read-only property set by the -Window Manager. If a Client wants to activate -another window, it MUST send a _NET_ACTIVE_WINDOW client message to the root -window: - - - _NET_WORKAREA - - - -This property MUST be set by the Window Manager upon calculating the work area for -each desktop. Contains a geometry for each desktop. These geometries are -specified relative to the viewport on each desktop and specify an area that is -completely contained within the viewport. - Work area SHOULD be used by desktop applications to place desktop icons appropriately. - - -The Window Manager SHOULD calculate this space by taking the current -page minus space occupied by dock and panel windows, as indicated by -the _NET_WM_STRUT or _NET_WM_STRUT_PARTIAL properties set on -client windows. - - - - _NET_SUPPORTING_WM_CHECK - - -The Window Manager MUST set this property on the root window to be the ID of a - child window created by himself, to indicate that a compliant window manager is - active. The child window MUST also have the _NET_SUPPORTING_WM_CHECK - property set to the ID of the child window. The child window MUST also - have the _NET_WM_NAME property set to the name of the Window Manager. - - -Rationale: The child window is used to distinguish an active Window Manager - from a stale _NET_SUPPORTING_WM_CHECK - property that happens to point to another window. If the - _NET_SUPPORTING_WM_CHECK window on the client window is missing - or not properly set, clients SHOULD assume that no conforming - Window Manager is present. - - - - _NET_VIRTUAL_ROOTS - - -To implement virtual desktops, some Window Managers reparent client windows to -a child of the root window. Window Managers using this technique MUST set -this property to a list of IDs for windows that are acting as virtual root -windows. This property allows background setting programs to work with -virtual roots and allows clients to figure out the window manager frame windows of their -windows. - - - - _NET_DESKTOP_LAYOUT - - #define _NET_WM_ORIENTATION_HORZ 0 - #define _NET_WM_ORIENTATION_VERT 1 - - #define _NET_WM_TOPLEFT 0 - #define _NET_WM_TOPRIGHT 1 - #define _NET_WM_BOTTOMRIGHT 2 - #define _NET_WM_BOTTOMLEFT 3 - - - This property is set by a Pager, not by the Window - Manager. - When setting this property, the Pager must own a manager selection (as - defined in the ICCCM 2.8). The manager selection is called - _NET_DESKTOP_LAYOUT_Sn where - n is the screen number. The purpose of - this property is to allow the Window Manager to know the desktop - layout displayed by the Pager. - - - _NET_DESKTOP_LAYOUT describes the layout of virtual - desktops relative to each other. More specifically, it describes the layout - used by the owner of the manager selection. The Window Manager may use - this layout information or may choose to ignore it. - The property contains four values: the Pager orientation, the number of - desktops in the X direction, the number in the Y direction, and the - starting corner of the layout, i.e. the corner containing the first desktop. - - - Note: In order to inter-operate with Pagers implementing an earlier - draft of this document, Window Managers should accept a - _NET_DESKTOP_LAYOUT property of length 3 and - use _NET_WM_TOPLEFT as the starting corner in this case. - - - The virtual desktops are arranged in a rectangle with - rows rows and columns columns. - If rows times columns does not match - the total number of desktops as specified by - _NET_NUMBER_OF_DESKTOPS, the highest-numbered - workspaces are assumed to be nonexistent. Either rows or - columns (but not both) may be specified as 0 in which - case its actual value will be derived from _NET_NUMBER_OF_DESKTOPS. - - - When the orientation is _NET_WM_ORIENTATION_HORZ - the desktops are laid out in rows, with the first desktop in the - specified starting corner. So a layout with four columns and three rows - starting in the _NET_WM_TOPLEFT corner looks like this: - - +--+--+--+--+ - | 0| 1| 2| 3| - +--+--+--+--+ - | 4| 5| 6| 7| - +--+--+--+--+ - | 8| 9|10|11| - +--+--+--+--+ - -With starting_corner _NET_WM_BOTTOMRIGHT, it looks like this: - - +--+--+--+--+ - |11|10| 9| 8| - +--+--+--+--+ - | 7| 6| 5| 4| - +--+--+--+--+ - | 3| 2| 1| 0| - +--+--+--+--+ - - - - - When the orientation is _NET_WM_ORIENTATION_VERT - the layout with four columns and three rows starting in the _NET_WM_TOPLEFT - corner looks like: - - - +--+--+--+--+ - | 0| 3| 6| 9| - +--+--+--+--+ - | 1| 4| 7|10| - +--+--+--+--+ - | 2| 5| 8|11| - +--+--+--+--+ - -With starting_corner _NET_WM_TOPRIGHT, it looks like: - - - +--+--+--+--+ - | 9| 6| 3| 0| - +--+--+--+--+ - |10| 7| 4| 1| - +--+--+--+--+ - |11| 8| 5| 2| - +--+--+--+--+ - - - - The numbers here are the desktop numbers, as for - _NET_CURRENT_DESKTOP. - - - - _NET_SHOWING_DESKTOP - - - Some Window Managers have a "showing the desktop" mode in which windows - are hidden, and the desktop background is displayed and focused. If a - Window Manager supports the _NET_SHOWING_DESKTOP hint, it MUST set it - to a value of 1 when the Window Manager is in "showing the desktop" mode, - and a value of zero if the Window Manager is not in this mode. - - - If a Pager wants to enter or leave the mode, it MUST - send a _NET_SHOWING_DESKTOP client message to the root window - requesting the change: - - The Window Manager may choose to ignore this client message. - - - - - - Other Root Window Messages - _NET_CLOSE_WINDOW - - - Pagers wanting to close a window MUST send a _NET_CLOSE_WINDOW client - message request to the root window: - - - -The Window Manager MUST then attempt to close the window specified. - - - Rationale: A Window Manager might be more clever than the usual method (send WM_DELETE message if the protocol is selected, XKillClient otherwise). It might introduce a timeout, for example. Instead of duplicating the code, the Window Manager can easily do the job. - - - _NET_MOVERESIZE_WINDOW - - - The low byte of data.l[0] contains the gravity to use; it may contain - any value allowed for the WM_SIZE_HINTS.win_gravity property: - NorthWest (1), North (2), NorthEast (3), West (4), Center (5), East - (6), SouthWest (7), South (8), SouthEast (9) and Static (10). A - gravity of 0 indicates that the Window Manager should use the gravity - specified in WM_SIZE_HINTS.win_gravity. The bits 8 to 11 indicate the - presence of x, y, width and height. - - - Pagers wanting to move or resize a window may send a - _NET_MOVERESIZE_WINDOW client message request to the root window - instead of using a ConfigureRequest. - - - Window Managers should treat a _NET_MOVERESIZE_WINDOW message exactly - like a ConfigureRequest (in particular, adhering to the ICCCM rules - about synthetic ConfigureNotify events), except that they should use - the gravity specified in the message. - - - Rationale: Using a _NET_MOVERESIZE_WINDOW message with StaticGravity - allows Pagers to exactly position and resize a window including its - decorations without knowing the size of the decorations. - - - _NET_WM_MOVERESIZE - - - This message allows Clients to initiate window movement or - resizing. They can define their own move and size - "grips", whilst letting the Window Manager control the actual operation. - This means that all moves/resizes can happen in a consistent manner as - defined by the Window Manager. - - - When sending this message in response to a button press event, button - SHOULD indicate the button which was pressed, x_root and y_root MUST - indicate the position of the button press with respect to the root - window and direction MUST indicate whether this is a move or resize - event, and if it is a resize event, which edges of the window the size - grip applies to. When sending this message in response to a key event, - the direction MUST indicate whether this this is a move or resize - event and the other fields are unused. - - - - The Client MUST release all grabs prior to sending such message. - - - The Window Manager can use the button field to determine the - events on which it terminates the operation initiated by the - _NET_WM_MOVERESIZE message. Since there is a race condition between - a client sending the _NET_WM_MOVERESIZE message and the user releasing - the button, Window Managers are advised to offer some other means to - terminate the operation, e.g. by pressing the ESC key. - - - - - Application Window Properties - _NET_WM_NAME - - -The Client SHOULD set this to the title of the window in UTF-8 encoding. If -set, the Window Manager should use this in preference to WM_NAME. - - - - _NET_WM_VISIBLE_NAME - - -If the Window Manager displays a window name other than _NET_WM_NAME the Window Manager MUST set this to the title displayed in UTF-8 encoding. - - -Rationale: This property is for Window Managers that display a title different from the _NET_WM_NAME or WM_NAME of the window (i.e. xterm <1>, xterm <2>, ... is shown, but _NET_WM_NAME / WM_NAME is still xterm for each window) thereby allowing Pagers to display the same title as the Window Manager. - - - - _NET_WM_ICON_NAME - - -The Client SHOULD set this to the title of the icon for this window in UTF-8 -encoding. If set, the Window Manager should use this in preference to -WM_ICON_NAME. - - - - _NET_WM_VISIBLE_ICON_NAME - - -If the Window Manager displays an icon name other than _NET_WM_ICON_NAME -the Window Manager MUST set this to the title displayed in UTF-8 encoding. - - - - _NET_WM_DESKTOP - - -Cardinal to determine the desktop the window is in (or wants to be) starting -with 0 for the first desktop. A Client MAY choose not to set this property, -in which case the Window Manager SHOULD place it as it wishes. 0xFFFFFFFF -indicates that the window SHOULD appear on all desktops. - - -The Window Manager should honor _NET_WM_DESKTOP whenever a withdrawn window -requests to be mapped. - - -The Window Manager should remove the property whenever -a window is withdrawn but it should leave the property in place when it is -shutting down, e.g. in response to losing ownership of the WM_Sn manager -selection. - - -Rationale: Removing the property upon window withdrawal helps legacy -applications which want to reuse withdrawn windows. Not removing the property -upon shutdown allows the next Window Manager to restore windows to their -previous desktops. - - -A Client can request a change of desktop for a non-withdrawn window by sending -a _NET_WM_DESKTOP client message to the root window: - - - - The Window Manager MUST keep this property updated on all windows. - - _NET_WM_WINDOW_TYPE - - -This SHOULD be set by the Client before mapping to a list of atoms indicating -the functional type of the window. This property SHOULD be used by the window -manager in determining the decoration, stacking position and other behavior -of the window. The Client SHOULD specify window types in order of preference -(the first being most preferable) but MUST include at least one of the basic -window type atoms from the list below. This is to allow for extension of the -list of types whilst providing default behavior for Window Managers that do -not recognize the extensions. - - -Rationale: This hint is intended to replace the MOTIF hints. One of the -objections to the MOTIF hints is that they are a purely visual description of -the window decoration. By describing the function of the window, the Window -Manager can apply consistent decoration and behavior to windows of the same -type. Possible examples of behavior include keeping dock/panels on top or -allowing pinnable menus / toolbars to only be hidden when another window has -focus (NextStep style). - - - -_NET_WM_WINDOW_TYPE_DESKTOP indicates a desktop feature. This can include a -single window containing desktop icons with the same dimensions as the screen, -allowing the desktop environment to have full control of the desktop, without -the need for proxying root window clicks. - - -_NET_WM_WINDOW_TYPE_DOCK indicates a dock or panel feature. Typically a -Window Manager would keep such windows on top of all other windows. - - -_NET_WM_WINDOW_TYPE_TOOLBAR and _NET_WM_WINDOW_TYPE_MENU indicate toolbar and -pinnable menu windows, respectively (i.e. toolbars and menus "torn off" from -the main application). Windows of this type may set the WM_TRANSIENT_FOR -hint indicating the main application window. - - -_NET_WM_WINDOW_TYPE_UTILITY indicates a small persistent utility window, such as -a palette or toolbox. It is distinct from type TOOLBAR because it does not -correspond to a toolbar torn off from the main application. It's distinct from -type DIALOG because it isn't a transient dialog, the user will probably keep it -open while they're working. Windows of this type may set the WM_TRANSIENT_FOR -hint indicating the main application window. - - -_NET_WM_WINDOW_TYPE_SPLASH indicates that the window is a splash screen -displayed as an application is starting up. - - -_NET_WM_WINDOW_TYPE_DIALOG indicates that this is a dialog window. If -_NET_WM_WINDOW_TYPE is not set, then windows with WM_TRANSIENT_FOR set MUST -be taken as this type. - - -_NET_WM_WINDOW_TYPE_NORMAL indicates that this is a normal, top-level window. -Windows with neither _NET_WM_WINDOW_TYPE nor WM_TRANSIENT_FOR set MUST -be taken as this type. - - - - _NET_WM_STATE - - -A list of hints describing the window state. Atoms present in the list MUST be -considered set, atoms not present in the list MUST be considered not set. The -Window Manager SHOULD honor -_NET_WM_STATE whenever a withdrawn window requests to be mapped. A Client -wishing to change the state of a window MUST send a _NET_WM_STATE client -message to the root window (see below). The Window Manager MUST keep this -property updated to reflect the current state of the window. - - -The Window Manager should remove the property whenever -a window is withdrawn, but it should leave the property in place when it is -shutting down, e.g. in response to losing ownership of the WM_Sn manager -selection. - - -Rationale: Removing the property upon window withdrawal helps legacy -applications which want to reuse withdrawn windows. Not removing the property -upon shutdown allows the next Window Manager to restore windows to their -previous state. - - -Possible atoms are: - - - -An implementation MAY add new atoms to this list. Implementations -without extensions MUST ignore any unknown atoms, effectively removing -them from the list. These extension atoms MUST NOT start with the prefix -_NET. - - -_NET_WM_STATE_MODAL indicates that this is a modal dialog box. -If the WM_TRANSIENT_FOR hint is set to another toplevel window, the -dialog is modal for that window; if WM_TRANSIENT_FOR is not set or set -to the root window the dialog is modal for its window group. - - -_NET_WM_STATE_STICKY indicates that the Window Manager SHOULD keep the -window's position fixed on the screen, even when the virtual desktop scrolls. - - -_NET_WM_STATE_MAXIMIZED_{VERT,HORZ} indicates that the window is -{vertically,horizontally} maximized. - - -_NET_WM_STATE_SHADED indicates that the window is shaded. - - -_NET_WM_STATE_SKIP_TASKBAR indicates that the window should not be -included on a taskbar. This hint should be requested by the -application, i.e. it indicates that the window by nature is never -in the taskbar. Applications should not set this hint if -_NET_WM_WINDOW_TYPE already conveys the exact nature of the -window. - - -_NET_WM_STATE_SKIP_PAGER indicates that the window should not be -included on a Pager. This hint should be requested by the application, -i.e. it indicates that the window by nature is never in the -Pager. Applications should not set this hint if _NET_WM_WINDOW_TYPE -already conveys the exact nature of the window. - - -_NET_WM_STATE_HIDDEN should be set by the Window Manager to indicate -that a window would not be visible on the screen if its -desktop/viewport were active and its coordinates were within the -screen bounds. The canonical example is that minimized windows should -be in the _NET_WM_STATE_HIDDEN state. Pagers and similar applications -should use _NET_WM_STATE_HIDDEN instead of WM_STATE to decide whether -to display a window in miniature representations of the windows on a -desktop. - - -Implementation note: if an Application asks to toggle -_NET_WM_STATE_HIDDEN the Window Manager should probably just ignore -the request, since _NET_WM_STATE_HIDDEN is a function of some other -aspect of the window such as minimization, rather than an independent -state. - - -_NET_WM_STATE_FULLSCREEN indicates that the window should fill the entire - screen and have no window decorations. For example, a presentation - program would use this hint. - - -_NET_WM_STATE_ABOVE indicates that the window should be on top of most -windows (see for details). - - - -_NET_WM_STATE_BELOW indicates that the window should be below most -windows (see for details). - - - - _NET_WM_STATE_ABOVE and _NET_WM_STATE_BELOW are mainly meant for user - preferences and should not be used by applications e.g. for drawing - attention to their dialogs (the Urgency - hint should be used in that case, see ).' - - - -To change the state of a mapped window, a Client MUST send a _NET_WM_STATE -client message to the root window (window is the respective window, type -_NET_WM_STATE, format 32, l[0]=<the action, as listed below>, -l[1]=<First property to alter>, l[2]=<Second property to alter>). -This message allows two properties to be changed simultaneously, specifically -to allow both horizontal and vertical maximization to be altered together. -l[2] MUST be set to zero if only one property is to be changed. l[0], the -action, MUST be one of: - - - - See also the implementation notes on urgency and fixed size windows. - - - - - _NET_WM_ALLOWED_ACTIONS - - -A list of atoms indicating user operations that the Window Manager supports for -this window. Atoms present in the list indicate allowed actions, atoms not -present in the list indicate actions that are not supported for this window. -The Window Manager MUST keep this property updated to reflect the -actions which are currently "active" or "sensitive" for a window. -Taskbars, Pagers, and other tools use _NET_WM_ALLOWED_ACTIONS to -decide which actions should be made available to the user. - - -Possible atoms are: - - - -An implementation MAY add new atoms to this list. Implementations -without extensions MUST ignore any unknown atoms, effectively removing -them from the list. These extension atoms MUST NOT start with the prefix -_NET. - - -Note that the actions listed here are those that the Window -Manager will honor for this window. The operations must still be -requested through the normal mechanisms outlined in this specification. For -example, _NET_WM_ACTION_CLOSE does not mean that clients can send a -WM_DELETE_WINDOW message to this window; it means that clients can use a -_NET_CLOSE_WINDOW message to ask the Window Manager to do so. - - -Window Managers SHOULD ignore the value of _NET_WM_ALLOWED_ACTIONS when they -initially manage a window. This value may be left over from a previous Window -Manager with different policies. - - -_NET_WM_ACTION_MOVE indicates that the window may be moved around the screen. - - -_NET_WM_ACTION_RESIZE indicates that the window may be resized. -(Implementation note: Window Managers can identify a non-resizable -window because its minimum and maximum size in WM_NORMAL_HINTS will be the same.) - - -_NET_WM_ACTION_MINIMIZE indicates that the window may be iconified. - - -_NET_WM_ACTION_SHADE indicates that the window may be shaded. - - -_NET_WM_ACTION_STICK indicates that the window may have its sticky state -toggled (as for _NET_WM_STATE_STICKY). Note that this state has to do with -viewports, not desktops. - - -_NET_WM_ACTION_MAXIMIZE_HORZ indicates that the window may be maximized horizontally. - - -_NET_WM_ACTION_MAXIMIZE_VERT indicates that the window may be maximized vertically. - - -_NET_WM_ACTION_FULLSCREEN indicates that the window may be brought to - fullscreen state. - - -_NET_WM_ACTION_CHANGE_DESKTOP indicates that the window may be moved between desktops. - - -_NET_WM_ACTION_CLOSE indicates that the window may be closed (i.e. a WM_DELETE_WINDOW -message may be sent). - - - -_NET_WM_STRUT - - -This property is equivalent to a _NET_WM_STRUT_PARTIAL property where all start -values are 0 and all end values are the height or width of the logical screen. -_NET_WM_STRUT_PARTIAL was introduced later than _NET_WM_STRUT, however, so -clients MAY set this property in addition to _NET_WM_STRUT_PARTIAL to ensure -backward compatibility with Window Managers supporting older versions of the -Specification. - - -_NET_WM_STRUT_PARTIAL - - -This property MUST be set by the Client if the window is to reserve space at the -edge of the screen. The property contains 4 cardinals specifying the width of -the reserved area at each border of the screen, and an additional 8 cardinals -specifying the beginning and end corresponding to each of the four struts. The -order of the values is left, right, top, bottom, left_start_y, left_end_y, -right_start_y, right_end_y, top_start_x, top_end_x, bottom_start_x, -bottom_end_x. All coordinates are root window coordinates. The client MAY change -this property at any time, therefore the Window Manager MUST watch for -property notify events if the Window Manager uses this property to assign -special semantics to the window. - - -If both this property and the _NET_WM_STRUT property are set, the Window Manager -MUST ignore the _NET_WM_STRUT property values and use instead the values for -_NET_WM_STRUT_PARTIAL. This will ensure that Clients can safely set both -properties without giving up the improved semantics of the new property. - - -The purpose of struts is to reserve space at the borders of the -desktop. This is very useful for a docking area, a taskbar or a panel, -for instance. The Window Manager should take this reserved area into -account when constraining window positions - maximized windows, for -example, should not cover that area. - - -The start and end values associated with each strut allow areas to be -reserved which do not span the entire width or height of the screen. -Struts MUST be specified in root window coordinates, that is, they are -not relative to the edges of any view port or Xinerama -monitor. - - -For example, for a panel-style Client appearing at the bottom of the -screen, 50 pixels tall, and occupying the space from 200-600 pixels -from the left of the screen edge would set a bottom strut of 50, and -set bottom_start_x to 200 and bottom_end_x to 600. Another example is -a panel on a screen using the Xinerama extension. Assume that the set -up uses two monitors, one running at 1280x1024 and the other to the -right running at 1024x768, with the top edge of the two physical -displays aligned. If the panel wants to fill the entire bottom edge -of the smaller display with a panel 50 pixels tall, it should set a -bottom strut of 306, with bottom_start_x of 1280, and bottom_end_x of -2303. Note that the strut is relative to the screen edge, and not the -edge of the xinerama monitor. - - -Rationale: A simple "do not cover" hint is not enough for dealing with e.g. -auto-hide panels. - - -Notes: An auto-hide panel SHOULD set the strut to be its minimum, hidden size. -A "corner" panel that does not extend for the full length of a screen border -SHOULD only set one strut. - - -_NET_WM_ICON_GEOMETRY - - -This optional property MAY be set by stand alone tools like a taskbar or an -iconbox. It specifies the geometry of a possible icon in case the window is iconified. - - -Rationale: This makes it possible for a Window Manager to display a nice -animation like morphing the window into its icon. - - - - _NET_WM_ICON - - -This is an array of possible icons for the client. This specification does -not stipulate what size these icons should be, but individual desktop -environments or toolkits may do so. The Window Manager MAY scale any of these -icons to an appropriate size. - - -This is an array of 32bit packed CARDINAL ARGB with high byte being A, low -byte being B. The first two cardinals are width, height. Data is in rows, left to -right and top to bottom. - - - - _NET_WM_PID - - -If set, this property MUST contain the process ID of the client owning this -window. This MAY be used by the Window Manager to kill windows which do not -respond to the _NET_WM_PING protocol. - - -If _NET_WM_PID is set, the ICCCM-specified property WM_CLIENT_MACHINE -MUST also be set. While the ICCCM only requests that WM_CLIENT_MACHINE is set - to a string that forms the name of the machine running the client as -seen from the machine running the server conformance to this -specification requires that WM_CLIENT_MACHINE be set to the fully-qualified domain -name of the client's host. - - -See also the implementation notes on killing hung processes. - - - _NET_WM_HANDLED_ICONS - - - This property can be set by a Pager on one of its own toplevel windows - to indicate that the Window Manager need not provide icons for - iconified windows, for example if it is a taskbar and provides buttons - for iconified windows. - - - - - Window Manager Protocols - - _NET_WM_PING - -This protocol allows the Window Manager to determine if the Client is still -processing X events. This can be used by the Window Manager to determine if a -window which fails to close after being sent WM_DELETE_WINDOW has stopped -responding or has stalled for some other reason, such as waiting for user -confirmation. A Client SHOULD indicate that it is willing to participate in -this protocol by listing _NET_WM_PING in the WM_PROTOCOLS property of the -client window. - - -A Window Manager can use this protocol at any time by sending a client message -as follows: - - - -A participating Client receiving this message MUST send it back to the root -window immediately, by setting window = root, and calling XSendEvent. The -Client MUST NOT alter the timestamp, as this can be used by the Window Manager -to uniquely identify the ping. - - -The Window Manager MAY kill the Client (using _NET_WM_PID) if it fails to -respond to this protocol within a reasonable time. - - -See also the implementation notes on killing hung processes. - - - - - Implementation notes - - 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. - - - - 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). - - - - 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 behavior is -pretty standard for many toolkits and window managers, and is extremely -unlikely to break anything, it seems reasonable to document it as standard. - - - - Urgency - -Windows expecting immediate user action should indicate this using the -urgency bit in the WM_HINTS.flags property, as defined in the ICCCM. - - - - 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. - - - - Pagers and Taskbars - - This specification attempts to make reasonable provisions for window - manager 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 communicate with the Window Manager using further, - window manager specific hints, or some other means. - - - Pagers should decide whether to show a miniature version of a - window using the following guidelines: - - - - If either _NET_WM_STATE_SKIP_PAGER or - _NET_WM_STATE_HIDDEN are set on a window, then the - pager should not show that window. - - - - - The pager may choose not to display windows with - certain semantic types; this spec has no - recommendations, but common practice is to avoid - displaying _NET_WM_WINDOW_TYPE_DOCK for example. - - - - - If the _NET_WM_STATE_SKIP_PAGER and - _NET_WM_STATE_HIDDEN hints are not present, and the - Window Manager claims to support _NET_WM_STATE_HIDDEN, - then the window should be shown if it's in either - NormalState or IconicState. - - - - - For Window Managers that do not support - _NET_WM_STATE_HIDDEN, the pager should - not show windows in IconicState. These Window - Managers are probably using an older version - of this specification. - - - - - - - Window Geometry - -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: - - - -Window Managers MUST honor the win_gravity field of WM_NORMAL_HINTS -for both MapRequest and ConfigureRequest events -(ICCCM Version 2.0, §4.1.2.3 and §4.1.5) - - -When generating synthetic ConfigureNotify events, the position given -MUST be the top-left corner of the client window in relation to the -origin of the root window (i.e., ignoring win_gravity) -(ICCCM Version 2.0, §4.2.3) - - -Window Managers maintain a reference point for each client window and place -the window relative to this reference point depending on the window's -win_gravity as follows: - - - - - - win_gravity: - placed at the reference point - - - StaticGravity - the left top corner of the client window - - - NorthWestGravity - the left top corner of the frame window - - - NorthGravity - the center of the frame window's top side - - - NorthEastGravity - the right top corner of the frame window - - - EastGravity - the center of the frame window's right side - - - SouthEastGravity - the right bottom corner of the frame window - - - SouthGravity - the center of the frame window's bottom side - - - SouthWestGravity - the left bottom corner of the frame window - - - WestGravity - the center of the frame window's left side - - - CenterGravity - the center of the frame window - - - - - - -Applications are free to change their win_gravity setting at any time. - - -If an Application changes its win_gravity then the Window Manager should -adjust the reference point, so that the client window will not move as the -result. For example if the Application's win_gravity was NorthWestGravity and -reference point was at the top-left corner of the frame window, then after -change of win_gravity to SouthEastGravity the reference point should be -adjusted to point to the lower-right corner of the frame. - - - -Changing the win_gravity for a single configure request and back afterwards is -unlikely to work as intended, due to a race condition. The window manager sees -a property notify for WM_NORMAL_HINTS, followed by the configure request, -followed by another property notify for WM_NORMAL_HINTS. By the time the -window manager gets around to request the changed WM_NORMAL_HINTS in response -to the first property notify, the server may have already processed the second -property change. - - -If the window manager supports it, applications should use -_NET_MOVERESIZE_WINDOW with a specified gravity to avoid this problem. - - - - -If the Application requests a new position (x, y) (and possibly also a -new size), the Window Manager calculates a new reference point (ref_x, ref_y), -based on the client window's (possibly new) size (width, height), border -width (bw) and win_gravity as explained in the table below. - - -The Window Manager will use the new reference point until the next request for -a new position. - - - - - - win_gravity: - ref_x: - ref_y: - - - StaticGravity - x - y - - - NorthWestGravity - x-bw - y-bw - - - NorthGravity - x+(width/2) - y-bw - - - NorthEastGravity - x+width+bw - y-bw - - - EastGravity - x+width+bw - y+(height/2) - - - SouthEastGravity - x+width+bw - y+height+bw - - - SouthGravity - x+(width/2) - y+height+bw - - - SouthWestGravity - x-bw - y+height+bw - - - WestGravity - x-bw - y+(height/2) - - - CenterGravity - x+(width/2) - y+(height/2) - - - - - - -If an Application requests just a new size, its reference point does not -move. So for example if client window has win_gravity SouthEastGravity and -is resized, the bottom right corner of its frame will not move but instead -the top left corner will be adjusted by the difference in size. - - -When calculating the reference point at the time of initial placement, -the Window Manager should take the initial window's size into consideration, -as if it was the frame for this window. - - - - - 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. - - - - 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 is usually set by calling XSetWMProperties(). The hostname for the current host can be be retrieved using gethostname(), when gethostname() -is not available on the platform implementors may use the value of the -nodename field of struct utsname as returned by uname(). Note also that the value of WM_CLIENT_MACHINE is not guaranteed -to be a fully fully-qualified domain name of the host. An example of how to -retrieve the hostname: - - - = maxlen) len = maxlen - 1; - strncpy (buf, name.nodename, len); - buf[len] = '\0'; - - return len; -#endif -} -]]> - - - - - Stacking order - - To obtain good interoperability between different Desktop Environments, - the following layered stacking order is recommended, from the bottom: - - windows of type _NET_WM_TYPE_DESKTOP - windows having state _NET_WM_STATE_BELOW - windows not belonging in any other layer - windows of type _NET_WM_TYPE_DOCK (unless they have - state _NET_WM_TYPE_BELOW) and windows having state - _NET_WM_STATE_ABOVE - focused windows having state - _NET_WM_STATE_FULLSCREEN - - - - Windows that are transient for another window should be kept - above this window. - - - The window manager may choose to put some windows in different - stacking positions, for example to allow the user to bring currently - a active window to the top and return it back when the window looses - focus. - - - - - References - - - [UTF8] - - - F. Yergeau,"UTF-8, a transformation format of ISO 10646", RFC 2279 - - - - - [ICCCM] - - - David Rosenthal and Stuart W. Marks, "Inter-Client Communication - Conventions Manual (Version 2.0)", X Consortium Standard, X Version 11, - Release 6.3 - - - - - - - Copyright - -Copyright (C) 2000-2003 See Contributors List - - -Permission is hereby granted, free of charge, to any person -obtaining a copy of this software and associated documentation -files (the "Software"), to deal in the Software without -restriction, including without limitation the rights to use, -copy, modify, merge, publish, distribute, sublicense, and/or -sell copies of the Software, and to permit persons to whom -the Software is furnished to do so, subject to the following -conditions: - - -The above copyright notice and this permission notice shall -be included in all copies or substantial portions of the -Software. - - -THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY -KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE -WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE -AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS -BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, -WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING -FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE -OR OTHER DEALINGS IN THE SOFTWARE. - - - - Contributors - - Sasha Vasko - Bradley T. Hughes - Dominik Vogt - Havoc Pennington - Jeff Raven - Jim Gettys - John Harper - Julian Adams - Matthias Ettrich - Micheal Rogers - Nathan Clemons - Tim Janik - Tomi Ollila - Sam Lantinga - The Rasterman - Paul Warren - Owen Taylor - Marko Macek - Greg Badros - Matthias Clasen - David Rosenthal - Lubos Lunak - Rob Adams - - - Change history - - Changes since 1.2 - - -Added new property _NET_WM_STRUT_PARTIAL to allow partial-width struts. - - -Rewrote the implementation notes on "Window Movement", retitled it -to "Window Geometry". - - -Rewrote the implementation notes on "Urgency", making it clear that -the hint is not just about dialogs. - - -Fixed the specification of the X and Y members of _NET_DESKTOP_LAYOUT -and renamed them to columns and row for clarity. - - -Change the description of _NET_WM_STATE_MODAL to no longer require apps to -break the ICCCM for group-modal windows, but still support the -WM_TRANSIENT_FOR=root dialect. - - - - - Changes since 1.1 - - - Changed WM_CLIENT_NAME(STRING) from suggested to required for _NET_WM_PID. - - - Specification and sample code for the content of WM_CLIENT_NAME(STRING). - - - Added _NET_WM_WINDOW_TYPE_SPLASH, _NET_WM_WINDOW_TYPE_UTILITY. - - - Added _NET_WM_STATE_FULLSCREEN. - - - Added _NET_WM_ALLOWED_ACTIONS. - - - Added _NET_WM_STATE_HIDDEN and clarified purpose of - _NET_WM_STATE_SKIP_PAGER and _NET_WM_STATE_SKIP_TASKBAR. Changed - section on virtual desktop implementation to suggest ICCCM compliance - regarding IconicState, using _NET_WM_STATE_HIDDEN to avoid confusion. - Added implementation note for pagers on when to display a window. - - - Added button field and new directions for keyboard-initiated actions - to the _NET_WM_MOVERESIZE message. - - - Added advice on removing _NET_WM_STATE and _NET_WM_DESKTOP when a window - is withdrawn. - - - Added _NET_DESKTOP_LAYOUT to allow a Pager to specify inter-desktop geometry. - - - Added _NET_SHOWING_DESKTOP. - - - Added _NET_WM_STATE_ABOVE and _NET_WM_STATE_BELOW and a recommended layered - stacking order. - - - Added _NET_MOVERESIZE_WINDOW. - - - Improve markup of citations. - - - Explain _NET_DESKTOP_GEOMETRY and _NET_WM_HANDLED_ICONS in more detail and - improve the explanation of WM_CLIENT_MACHINE in - . - - - Add Lubos Lunak to the list of contributors. - - - - - Changes since 1.0 - - -Fix doctype, add author info, update data. - - -Change specification description wording to be more inclusive, and to reflect the joint nature of the specification. - - -Fix miscellaneous typographical, grammar and spelling errors. - - -Clarified _NET_SUPPORTED to include ALL atoms, not just the property names. - - -Various corrections to use of MUST and SHOULD. - - -Fix problem in _NET_WM_ICON where 'bytes' should have been 'cardinals' - - -Replaced ISO-8559-1 characters with entities. - - - - - Changes since 1.0pre5 - - -Change history moved to end. - - -UTF-8 Reference updated. - - -Window Gravity information updated. - - -Copyright Added. - - -Minor typo corrections. - - - - - Changes since 1.0pre4 - - -Clarified the interpretation of client-provided geometries on large desktops. - - -Added more explanation for _NET_DESKTOP_NAMES. - - -Added _NET_WM_ICON_NAME and _NET_WM_VISIBLE_ICON_NAME. - - -Tried to improve the wording of _NET_WM_STRUT explanation. - - -Changed _NET_WORKAREA to an array of viewport-relative geometries. - - -Updated list of dependent properties for _NET_NUMBER_OF_DESKTOPS -to include _NET_WORKAREA and _NET_DESKTOP_VIEWPORT. - - -Tidied formatting of all client messages. - - - - - Changes since 1.0pre3 - - -Added information about common non-ICCCM features. - - -Added explanation of sending messages to the root window. - - -Removed XA_ prefix from type names. - - -Clarified that mapping order refers to inital mapping -and specify the directions of both orders. - - -Clarified that desktops have a common size specified by _NET_DESKTOP_GEOMETRY. - - -Rewrote explanation of _NET_DESKTOP_VIEWPORT. - - -Tidied formatting of _NET_CURRENT_DESKTOP. - - -Replaced window handle by window ID. - - -Tidied formatting of _NET_WORKAREA. - - -Rewrote the motivation for _NET_VIRTUAL_ROOTS. - - -Added advice on Pointer grabs to _NET_WM_MOVERESIZE. - - -Fixed typos in _NET_WM_STATE. - - -Added _NET_WM_STATE_SKIP_PAGER. - - -Tidied formatting of _NET_WM_STRUT. - - -Tidied formatting of _NET_WM_ICON_GEOMETRY. - - - - - Changes since 1.0pre2 - - -_NET_SET_NUMBER_OF_DESKTOPS -> _NET_NUMBER_OF_DESKTOPS for consistency. - - -_NET_WM_VISIBLE_NAME_STRING -> _NET_WM_VISIBLE_NAME for consistency. - - -_NET_WM_STATE: added explanation of permitted extensions. Added explanation of -being set / not set. - - -Spellchecked, corrected various typos. - - -UTF8 -> UTF-8 for consistency. - - -added references to the ICCCM an UTF-8 (incomplete). - - -added data and event formats where missing. - - -clarified _NET_SUPPORTING_WM_CHECK. - - -fixed formatting of _NET_CLOSE_WINDOW message. - - - - - Changes since 1.0pre1 - - -Removed implementation note concerning Gnome's (potential) file manager behavior. - - -The Window Movement section of the implementation notes has been revised. - - - - - Changes since 1.9f - - -Revised revision number for first accepted release 1.9XX -> 1.0preXX. - - -Prerequisites for adoption of this specification added. - - -Tidied formatting of _NET_CURRENT_DESKTOP for consistency. - - -Tidied formatting of _NET_ACTIVE_WINDOW for consistency. Removed doubled text. - - -Tidied formatting of _NET_WM_DESKTOP for consistency. - - -Killing Hung Processes implementation note added. _NET_WM_PID and _NET_WM_PING now link to this. - - -Clarified x_root and y_root meaning for _NET_WM_MOVERESIZE. - - -Added contributor list. - - - - - Changes since 1.9e - - -Added _NET_WM_VISIBLE_NAME_STRING - - -Removed ambiguity from _NET_NUMBER_OF_DESKTOPS and _NET_DESKTOP_NAMES in combination. - - -Set _NET_WM_MOVERESIZE format to 32 for consistency. - - -Removed _NET_PROPERTIES. - - -Removed comment from _NET_WM_MOVERESIZE. - - - - - Changes since 1.9d - - -Added _NET_VIRTUAL_ROOTS - - -Added note about ICCCM compliant window moves. - - -Added _NET_WM_HANDLED_ICONS - - -Added _NET_SUPPORTING_WM_CHECK - - -Removed degrees of activation - - - - - Changes since 1.9c - - - -Removed packaging of hints into 2 X properties. Jim Gettys points out that the -performance gains of fewer round trips can be better achieved using Xlib -routines. - - - - -Clarified that _NET_DESKTOP_VIEWPORT is in pixels - - - - -_NET_DESKTOP_VIEWPORT is now an array, one for each desktop, to allow for -different active viewports on different desktops - - - - -_NET_WM_STRUT now only applies on desktops on which the client is visible - - - - -Introduced RFC 2119 language, and attempted to clarify the roles of the Window -Manager, Pagers and Applications - - - - -Added _NET_WM_NAME - - - - -_NET_DESKTOP_NAMES now in UTF8 - - - - -Desktops now start from 0 - - - - -Added _NET_WM_PID - - - - -Added _NET_WM_PING protocol - - - - -Added _NET_WM_STATE_SKIP_TASKBAR - - - - - - - Changes since 1.9b - - Removed _NET_NUMBER_OF_DESKTOPS client message, as it overlaps unnecessarily with _NET_{INSERT/DELETE}_DESKTOP. - - Replaced _NET_WM_LAYER and _NET_WM_HINTS with _NET_WM_WINDOW_TYPE functional hint. - Changed _NET_WM_STATE to a list of atoms, for extensibility. - Expanded description of _NET_WORKAREA and _NET_WM_STRUT. - Removed _NET_WM_SIZEMOVE_NOTIFY protocol. - Added degrees of activation to _NET_ACTIVE_WINDOW client message - Added _NET_WM_ICON - My comments are in [[ ]]. Comments from Marko's draft are in [[MM: ]] - - - -
- diff --git a/wm-spec/wm-spec.xml b/wm-spec/wm-spec.xml new file mode 100644 index 0000000..3019eb7 --- /dev/null +++ b/wm-spec/wm-spec.xml @@ -0,0 +1,2153 @@ + + +]> +
+ + + + X Desktop Group + + +Extended Window Manager Hints +&date; +&version; + + + Introduction + + Version + +This is &version; of the Extended Window Manager Hints (EWMH) spec, updated +&date;. The canonical home for this document is http://www.freedesktop.org, +which also contains directions for reporting bugs or contributing to future +versions. + + + + What is this spec? + +This spec defines interactions between window managers, applications, +and the utilities that form part of a desktop environment. It builds +on the Inter-Client Communication Conventions Manual ICCCM, which defines +window manager interactions at a lower level. The ICCCM does not provide ways +to implement many features that modern desktop users expect. The GNOME and KDE +desktop projects originally developed their own extensions to the ICCCM to +support these features; this spec replaces those custom extensions +with a standardized set of ICCCM additions that any desktop +environment can adopt. + + + + Language used in this specification + +The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", +"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be +interpreted as described in RFC 2119. + + +The key words "Window Manager" refer to a window manager which is adopting this +specification. "Pager" refers to desktop utility applications, including +pagers and taskbars. "Application" refers to other clients. "Clients" refers +to Pagers and Applications ie. all X clients, except for the Window Manager. + + + + Prerequisites for adoption of this specification + +Window Managers and Clients which aim to fulfill this specification MUST adhere +to the ICCCM on which this specification builds. If this specification +explicitly modifies the ICCCM Window Managers and Clients MUST fulfill these +modifications. + + + + +Non-ICCCM features +There is a number of window management features or behaviors which are +not specified in the ICCCM, but are commonly met in modern window managers and desktop environments. + +Additional States +The ICCCM allows window managers to implement additional window states, which will +appear to clients as substates of NormalState and IconicState. Two +commonly met examples are Maximized and Shaded. A window manager may implement these +as proper substates of NormalState and IconicState, or it may treat them +as independent flags, allowing e.g. a maximized window to be iconified +and to re-appear as maximized upon de-iconification. + +Maximization +Maximization is a very old feature of window managers. There was even a ZoomedState +in early ICCCM drafts. Maximizing a window should give it as much of the +screen area as possible (this may not be the full screen area, but only +a smaller 'workarea', since the window manager may have reserved certain areas for other +windows). A window manager is expected to remember the geometry of a maximized window +and restore it upon de-maximization. Modern window managers typically allow separate +horizontal and vertical maximization. +With the introduction of the Xinerama extension in X11 R6.4, maximization +has become more involved. Xinerama allows a screen to span multiple +monitors in a freely configurable geometry. In such a setting, maximizing +a window would ideally not grow it to fill the whole screen, but only the +monitor it is shown on. There are of course borderline cases for windows +crossing monitor boundaries, and 'real' maximization to the full screen may +sometimes be useful. + + +Shading +Some desktop environments offer shading (also known as rollup) as an alternative to +iconification. A shaded window typically shows only the titlebar, the client +window is hidden, thus shading is not useful for windows which are not +decorated with a titlebar. + + + +Modality +The WM_TRANSIENT_FOR hint of the ICCCM allows clients to specify that a +toplevel window may be closed before the client finishes. A typical example +of a transient window is a dialog. Some dialogs can be open for a long time, +while the user continues to work in the main window. Other dialogs have to be +closed before the user can continue to work in the main window. This property +is called modality. While clients can implement modal windows in an ICCCM +compliant way using the globally active input model, some window managers offer support +for handling modality. + + + +Large Desktops +The window manager may offer to arrange the managed windows on a desktop that is +larger than the root window. The screen functions as a viewport on this large +desktop. Different policies regarding the positioning of the viewport on the +desktop can be implemented: The window manager may only allow the viewport +position to change in increments of the screen size (paging) or it may allow +arbitrary positions (scrolling). +To fulfill the ICCCM principle that clients should behave the same +regardless whether a window manager is running or not, window managers which +implement large desktops must interpret all client-provided geometries with +respect to the current viewport. + +Implementation note +There are two options for implementing a large desktop: The first is to +keep the managed windows (or, if reparenting, their frames) as children +of the root window. Moving the viewport is achieved by moving all managed +windows in the opposite direction. +The second alternative is to reparent all managed windows to a dedicated +large window (somewhat inappropriately called a 'virtual root'). Moving +the viewport is then achieved by moving the virtual root in the opposite +direction. +Both alternatives are completely ICCCM compliant, although the second one +may be somewhat problematic for clients trying to figure out the window manager decorations +around their toplevel windows and for clients trying to draw background +images on the root window. + + + +Sticky windows +A window manager which implements a large desktop typically offers a way for the user +to make certain windows 'stick to the glass', i.e. these windows will stay +at the same position on the screen when the viewport is moved. + + +Virtual Desktops +Most X servers have only a single screen. The window manager may virtualize this +resource and offer multiple so-called 'virtual desktops', of which only one +can be shown on the screen at a time. There is some variation among the +features of virtual desktop implementations. There may be a fixed number +of desktops, or new ones may be created dynamically. The size of the desktops +may be fixed or variable. If the desktops are larger than the root window, +their viewports (see ) may be independent or forced +to be at the same position. +A window manager which implements virtual desktops generally offers a way for the user +to move clients between desktops. Clients may be allowed to occupy more than +one desktop simultaneously. + +Implementation note +There are at least two options for implementing virtual desktops. +The first is to use multiple virtual roots (see ) and change the current +desktop by manipulating the stacking order of the virtual roots. This is +completely ICCCM compliant, but has the issues outlined in +The second option is to keep all managed windows as children of the root +window and unmap the frames of those which are not on the current +desktop. Unmapped windows should be placed in IconicState, according to +the ICCCM. Windows which are actually iconified or minimized +should have the _NET_WM_STATE_HIDDEN property set, to +communicate to pagers that the window should not be represented as +"onscreen." + + + + +Pagers +A pager offers a different UI for window management tasks. It shows a +miniature view of the desktop(s) representing managed windows by small +rectangles and allows the user to initiate various window manager actions by manipulating +these representations. Typically offered actions are activation (see ), +moving, restacking, iconification, maximization and closing. On a large +desktop, the pager may offer a way to move the viewport. On virtual desktops, +the pager may offer ways to move windows between desktops and to change the +current desktop. + + +Taskbars +A taskbar offers another UI for window management tasks. It typically +represents client windows as a list of buttons labelled with the window +titles and possibly icons. Pressing a button initiates a window manager action on the +represented window, typical actions being activation and iconification. +In environments with a taskbar, icons are often considered inappropriate, +since the iconified windows are already represented in the taskbar. + + +Activation +In the X world, activating a window means to give it the input focus. +This may not be possible if the window is unmapped, because it is on a +different desktop. Thus, activating a window may involve additional steps +like moving it to the current desktop (or changing to the desktop the window +is on), deiconifying it or raising it. + + +Animated iconification +Some window managers display some form of animation when (de-)iconifying a window. +This may be a line drawing connecting the corners of the window with +the corners of the icon or the window may be opaquely moved and resized +on some trajectory joining the window location and the icon location. + + +Window-in-window MDI +Window-in-window MDI is a multiple document interface known from MS +Windows platforms. Programs employing it have a single top-level window +which contains a workspace which contains the subwindows for the open +documents. These subwindows are decorated with window manager frames and can be +manipulated within their parent window just like ordinary top-level +windows on the root window. + + +Layered stacking order + +Some window managers keep the toplevel windows not in a single linear stack, +but subdivide the stack into several layers. There is a lot of variation +among the features of layered stacking order implementations. The number of +layers may or may not be fixed. The layer of a toplevel window may be explicit +and directly modifiable or derived from other properties of the window, e.g. +the type of the window. The stacking order may or may not +be strict, i.e. not allow the user to raise or lower windows beyond their +layer. + + + +Scope of this spec +This spec tries to address the following issues: + +Allow clients to influence their initial state with respect +to maximization, shading, stickiness, desktop, stacking order. +Improve the window managers ability to vary window +decorations and maintain the stacking order by allowing clients to hint the +window manager about the type of their windows. +Enable pagers and taskbars to be implemented as separate +clients and allow them to work with any compliant window manager. + +This spec doesn't cover any of the following: + +Other IPC mechanisms like ICE or Corba. +Window manager configuration. +Window manager documentation. +Clients appearing on a proper subset of desktops. +Window-in-window MDI. + +The window manager is supposed to be in charge of window management +policy, so that there is consistent behavior on the user's screen no matter +who wrote the clients. +The spec offers a lot of external control about window manager actions. +This is intended mainly to allow pagers, taskbars and similar window manager +UIs to be implemented as separate clients. "Ordinary" clients shouldn't use +these except maybe in response to a direct user request (i.e. setting a +config option to start maximized or specifying a -desk n command line +argument). + + + + Root Window Properties (and Related Messages) + +Whenever this spec speaks about sending a message to the root +window, it is understood that the client is supposed to create +a ClientMessage event with the specified contents and send it by using +a SendEvent request with the following arguments: + + + _NET_SUPPORTED + + +This property MUST be set by the Window Manager to indicate which hints it +supports. For example: considering _NET_WM_STATE +both this atom and all supported states e.g. _NET_WM_STATE_MODAL, +_NET_WM_STATE_STICKY, would be listed. This assumes that backwards +incompatible changes will not be made to the hints (without being renamed). + + _NET_CLIENT_LIST + + +These arrays contain all X Windows managed by the Window Manager. +_NET_CLIENT_LIST has initial mapping order, starting with the oldest window. +_NET_CLIENT_LIST_STACKING has bottom-to-top stacking order. These properties +SHOULD be set and updated by the Window Manager. + + + + _NET_NUMBER_OF_DESKTOPS + + +This property SHOULD be set and updated by the Window Manager to indicate the +number of virtual desktops. + + +A Pager can request a change in the number of desktops by sending a _NET_NUMBER_OF_DESKTOPS message to the root window: + + + +The Window Manager is free to honor or reject this request. If the request is honored _NET_NUMBER_OF_DESKTOPS MUST be set to the new number of desktops, _NET_VIRTUAL_ROOTS MUST be set to store the new number of desktop virtual root window IDs and _NET_DESKTOP_VIEWPORT and _NET_WORKAREA must also be changed accordingly. The _NET_DESKTOP_NAMES property MAY remain unchanged. + + +If the number of desktops is shrinking and _NET_CURRENT_DESKTOP is out of the new range of available desktops, then this MUST be set to the last available desktop from the new set. Clients that are still present on desktops that are out of the new range MUST be moved to the very last desktop from the new set. For these _NET_WM_DESKTOP MUST be updated. + + + + _NET_DESKTOP_GEOMETRY + + + Array of two cardinals that defines the common size of all desktops + (this is equal to the screen size if the Window Manager doesn't support + large desktops, otherwise it's equal to the virtual size of the + desktop). This property SHOULD be set by the Window Manager. + + +A Pager can request a change in the desktop geometry by sending a _NET_DESKTOP_GEOMETRY client +message to the root window: + + + +The Window Manager MAY choose to ignore this message, in which case _NET_DESKTOP_GEOMETRY property will remain unchanged. + + + + _NET_DESKTOP_VIEWPORT + + +Array of pairs of cardinals that define the top left corner of each desktop's +viewport. For Window Managers that don't support large desktops, this MUST +always be set to (0,0). + + +A Pager can request to change the viewport for the current desktop by sending a +_NET_DESKTOP_VIEWPORT client message to the root window: + + + +The Window Manager MAY choose to ignore this message, in which case _NET_DESKTOP_VIEWPORT property will remain unchanged. + + _NET_CURRENT_DESKTOP + + +The index of the current desktop. This is always an integer between 0 and +_NET_NUMBER_OF_DESKTOPS - 1. This MUST be set and updated by the Window +Manager. If a Pager wants to switch to another virtual desktop, it MUST send +a _NET_CURRENT_DESKTOP client message to the root window: + + + _NET_DESKTOP_NAMES + + +The names of all virtual desktops. This is a list of NULL-terminated strings in + UTF-8 encoding UTF8. This property MAY be + changed by a Pager or the Window Manager at any time. + + +Note: The number of names could be different from _NET_NUMBER_OF_DESKTOPS. +If it is less than _NET_NUMBER_OF_DESKTOPS, then the desktops with high +numbers are unnamed. If it is larger than _NET_NUMBER_OF_DESKTOPS, then the +excess names outside of the _NET_NUMBER_OF_DESKTOPS are considered to be +reserved in case the number of desktops is increased. + + +Rationale: The name is not a necessary attribute of a virtual desktop. Thus +the availability or unavailability of names has no impact on virtual desktop +functionality. Since names are set by users and users are likely to preset +names for a fixed number of desktops, it doesn't make sense to shrink or grow +this list when the number of available desktops changes. + + _NET_ACTIVE_WINDOW + + +The window ID of the currently active window or None if no window has the focus. +This is a read-only property set by the +Window Manager. If a Client wants to activate +another window, it MUST send a _NET_ACTIVE_WINDOW client message to the root +window: + + + _NET_WORKAREA + + + +This property MUST be set by the Window Manager upon calculating the work area for +each desktop. Contains a geometry for each desktop. These geometries are +specified relative to the viewport on each desktop and specify an area that is +completely contained within the viewport. + Work area SHOULD be used by desktop applications to place desktop icons appropriately. + + +The Window Manager SHOULD calculate this space by taking the current +page minus space occupied by dock and panel windows, as indicated by +the _NET_WM_STRUT or _NET_WM_STRUT_PARTIAL properties set on +client windows. + + + + _NET_SUPPORTING_WM_CHECK + + +The Window Manager MUST set this property on the root window to be the ID of a + child window created by himself, to indicate that a compliant window manager is + active. The child window MUST also have the _NET_SUPPORTING_WM_CHECK + property set to the ID of the child window. The child window MUST also + have the _NET_WM_NAME property set to the name of the Window Manager. + + +Rationale: The child window is used to distinguish an active Window Manager + from a stale _NET_SUPPORTING_WM_CHECK + property that happens to point to another window. If the + _NET_SUPPORTING_WM_CHECK window on the client window is missing + or not properly set, clients SHOULD assume that no conforming + Window Manager is present. + + + + _NET_VIRTUAL_ROOTS + + +To implement virtual desktops, some Window Managers reparent client windows to +a child of the root window. Window Managers using this technique MUST set +this property to a list of IDs for windows that are acting as virtual root +windows. This property allows background setting programs to work with +virtual roots and allows clients to figure out the window manager frame windows of their +windows. + + + + _NET_DESKTOP_LAYOUT + + #define _NET_WM_ORIENTATION_HORZ 0 + #define _NET_WM_ORIENTATION_VERT 1 + + #define _NET_WM_TOPLEFT 0 + #define _NET_WM_TOPRIGHT 1 + #define _NET_WM_BOTTOMRIGHT 2 + #define _NET_WM_BOTTOMLEFT 3 + + + This property is set by a Pager, not by the Window + Manager. + When setting this property, the Pager must own a manager selection (as + defined in the ICCCM 2.8). The manager selection is called + _NET_DESKTOP_LAYOUT_Sn where + n is the screen number. The purpose of + this property is to allow the Window Manager to know the desktop + layout displayed by the Pager. + + + _NET_DESKTOP_LAYOUT describes the layout of virtual + desktops relative to each other. More specifically, it describes the layout + used by the owner of the manager selection. The Window Manager may use + this layout information or may choose to ignore it. + The property contains four values: the Pager orientation, the number of + desktops in the X direction, the number in the Y direction, and the + starting corner of the layout, i.e. the corner containing the first desktop. + + + Note: In order to inter-operate with Pagers implementing an earlier + draft of this document, Window Managers should accept a + _NET_DESKTOP_LAYOUT property of length 3 and + use _NET_WM_TOPLEFT as the starting corner in this case. + + + The virtual desktops are arranged in a rectangle with + rows rows and columns columns. + If rows times columns does not match + the total number of desktops as specified by + _NET_NUMBER_OF_DESKTOPS, the highest-numbered + workspaces are assumed to be nonexistent. Either rows or + columns (but not both) may be specified as 0 in which + case its actual value will be derived from _NET_NUMBER_OF_DESKTOPS. + + + When the orientation is _NET_WM_ORIENTATION_HORZ + the desktops are laid out in rows, with the first desktop in the + specified starting corner. So a layout with four columns and three rows + starting in the _NET_WM_TOPLEFT corner looks like this: + + +--+--+--+--+ + | 0| 1| 2| 3| + +--+--+--+--+ + | 4| 5| 6| 7| + +--+--+--+--+ + | 8| 9|10|11| + +--+--+--+--+ + +With starting_corner _NET_WM_BOTTOMRIGHT, it looks like this: + + +--+--+--+--+ + |11|10| 9| 8| + +--+--+--+--+ + | 7| 6| 5| 4| + +--+--+--+--+ + | 3| 2| 1| 0| + +--+--+--+--+ + + + + + When the orientation is _NET_WM_ORIENTATION_VERT + the layout with four columns and three rows starting in the _NET_WM_TOPLEFT + corner looks like: + + + +--+--+--+--+ + | 0| 3| 6| 9| + +--+--+--+--+ + | 1| 4| 7|10| + +--+--+--+--+ + | 2| 5| 8|11| + +--+--+--+--+ + +With starting_corner _NET_WM_TOPRIGHT, it looks like: + + + +--+--+--+--+ + | 9| 6| 3| 0| + +--+--+--+--+ + |10| 7| 4| 1| + +--+--+--+--+ + |11| 8| 5| 2| + +--+--+--+--+ + + + + The numbers here are the desktop numbers, as for + _NET_CURRENT_DESKTOP. + + + + _NET_SHOWING_DESKTOP + + + Some Window Managers have a "showing the desktop" mode in which windows + are hidden, and the desktop background is displayed and focused. If a + Window Manager supports the _NET_SHOWING_DESKTOP hint, it MUST set it + to a value of 1 when the Window Manager is in "showing the desktop" mode, + and a value of zero if the Window Manager is not in this mode. + + + If a Pager wants to enter or leave the mode, it MUST + send a _NET_SHOWING_DESKTOP client message to the root window + requesting the change: + + The Window Manager may choose to ignore this client message. + + + + + + Other Root Window Messages + _NET_CLOSE_WINDOW + + + Pagers wanting to close a window MUST send a _NET_CLOSE_WINDOW client + message request to the root window: + + + +The Window Manager MUST then attempt to close the window specified. + + + Rationale: A Window Manager might be more clever than the usual method (send WM_DELETE message if the protocol is selected, XKillClient otherwise). It might introduce a timeout, for example. Instead of duplicating the code, the Window Manager can easily do the job. + + + _NET_MOVERESIZE_WINDOW + + + The low byte of data.l[0] contains the gravity to use; it may contain + any value allowed for the WM_SIZE_HINTS.win_gravity property: + NorthWest (1), North (2), NorthEast (3), West (4), Center (5), East + (6), SouthWest (7), South (8), SouthEast (9) and Static (10). A + gravity of 0 indicates that the Window Manager should use the gravity + specified in WM_SIZE_HINTS.win_gravity. The bits 8 to 11 indicate the + presence of x, y, width and height. + + + Pagers wanting to move or resize a window may send a + _NET_MOVERESIZE_WINDOW client message request to the root window + instead of using a ConfigureRequest. + + + Window Managers should treat a _NET_MOVERESIZE_WINDOW message exactly + like a ConfigureRequest (in particular, adhering to the ICCCM rules + about synthetic ConfigureNotify events), except that they should use + the gravity specified in the message. + + + Rationale: Using a _NET_MOVERESIZE_WINDOW message with StaticGravity + allows Pagers to exactly position and resize a window including its + decorations without knowing the size of the decorations. + + + _NET_WM_MOVERESIZE + + + This message allows Clients to initiate window movement or + resizing. They can define their own move and size + "grips", whilst letting the Window Manager control the actual operation. + This means that all moves/resizes can happen in a consistent manner as + defined by the Window Manager. + + + When sending this message in response to a button press event, button + SHOULD indicate the button which was pressed, x_root and y_root MUST + indicate the position of the button press with respect to the root + window and direction MUST indicate whether this is a move or resize + event, and if it is a resize event, which edges of the window the size + grip applies to. When sending this message in response to a key event, + the direction MUST indicate whether this this is a move or resize + event and the other fields are unused. + + + + The Client MUST release all grabs prior to sending such message. + + + The Window Manager can use the button field to determine the + events on which it terminates the operation initiated by the + _NET_WM_MOVERESIZE message. Since there is a race condition between + a client sending the _NET_WM_MOVERESIZE message and the user releasing + the button, Window Managers are advised to offer some other means to + terminate the operation, e.g. by pressing the ESC key. + + + + + Application Window Properties + _NET_WM_NAME + + +The Client SHOULD set this to the title of the window in UTF-8 encoding. If +set, the Window Manager should use this in preference to WM_NAME. + + + + _NET_WM_VISIBLE_NAME + + +If the Window Manager displays a window name other than _NET_WM_NAME the Window Manager MUST set this to the title displayed in UTF-8 encoding. + + +Rationale: This property is for Window Managers that display a title different from the _NET_WM_NAME or WM_NAME of the window (i.e. xterm <1>, xterm <2>, ... is shown, but _NET_WM_NAME / WM_NAME is still xterm for each window) thereby allowing Pagers to display the same title as the Window Manager. + + + + _NET_WM_ICON_NAME + + +The Client SHOULD set this to the title of the icon for this window in UTF-8 +encoding. If set, the Window Manager should use this in preference to +WM_ICON_NAME. + + + + _NET_WM_VISIBLE_ICON_NAME + + +If the Window Manager displays an icon name other than _NET_WM_ICON_NAME +the Window Manager MUST set this to the title displayed in UTF-8 encoding. + + + + _NET_WM_DESKTOP + + +Cardinal to determine the desktop the window is in (or wants to be) starting +with 0 for the first desktop. A Client MAY choose not to set this property, +in which case the Window Manager SHOULD place it as it wishes. 0xFFFFFFFF +indicates that the window SHOULD appear on all desktops. + + +The Window Manager should honor _NET_WM_DESKTOP whenever a withdrawn window +requests to be mapped. + + +The Window Manager should remove the property whenever +a window is withdrawn but it should leave the property in place when it is +shutting down, e.g. in response to losing ownership of the WM_Sn manager +selection. + + +Rationale: Removing the property upon window withdrawal helps legacy +applications which want to reuse withdrawn windows. Not removing the property +upon shutdown allows the next Window Manager to restore windows to their +previous desktops. + + +A Client can request a change of desktop for a non-withdrawn window by sending +a _NET_WM_DESKTOP client message to the root window: + + + + The Window Manager MUST keep this property updated on all windows. + + _NET_WM_WINDOW_TYPE + + +This SHOULD be set by the Client before mapping to a list of atoms indicating +the functional type of the window. This property SHOULD be used by the window +manager in determining the decoration, stacking position and other behavior +of the window. The Client SHOULD specify window types in order of preference +(the first being most preferable) but MUST include at least one of the basic +window type atoms from the list below. This is to allow for extension of the +list of types whilst providing default behavior for Window Managers that do +not recognize the extensions. + + +Rationale: This hint is intended to replace the MOTIF hints. One of the +objections to the MOTIF hints is that they are a purely visual description of +the window decoration. By describing the function of the window, the Window +Manager can apply consistent decoration and behavior to windows of the same +type. Possible examples of behavior include keeping dock/panels on top or +allowing pinnable menus / toolbars to only be hidden when another window has +focus (NextStep style). + + + +_NET_WM_WINDOW_TYPE_DESKTOP indicates a desktop feature. This can include a +single window containing desktop icons with the same dimensions as the screen, +allowing the desktop environment to have full control of the desktop, without +the need for proxying root window clicks. + + +_NET_WM_WINDOW_TYPE_DOCK indicates a dock or panel feature. Typically a +Window Manager would keep such windows on top of all other windows. + + +_NET_WM_WINDOW_TYPE_TOOLBAR and _NET_WM_WINDOW_TYPE_MENU indicate toolbar and +pinnable menu windows, respectively (i.e. toolbars and menus "torn off" from +the main application). Windows of this type may set the WM_TRANSIENT_FOR +hint indicating the main application window. + + +_NET_WM_WINDOW_TYPE_UTILITY indicates a small persistent utility window, such as +a palette or toolbox. It is distinct from type TOOLBAR because it does not +correspond to a toolbar torn off from the main application. It's distinct from +type DIALOG because it isn't a transient dialog, the user will probably keep it +open while they're working. Windows of this type may set the WM_TRANSIENT_FOR +hint indicating the main application window. + + +_NET_WM_WINDOW_TYPE_SPLASH indicates that the window is a splash screen +displayed as an application is starting up. + + +_NET_WM_WINDOW_TYPE_DIALOG indicates that this is a dialog window. If +_NET_WM_WINDOW_TYPE is not set, then windows with WM_TRANSIENT_FOR set MUST +be taken as this type. + + +_NET_WM_WINDOW_TYPE_NORMAL indicates that this is a normal, top-level window. +Windows with neither _NET_WM_WINDOW_TYPE nor WM_TRANSIENT_FOR set MUST +be taken as this type. + + + + _NET_WM_STATE + + +A list of hints describing the window state. Atoms present in the list MUST be +considered set, atoms not present in the list MUST be considered not set. The +Window Manager SHOULD honor +_NET_WM_STATE whenever a withdrawn window requests to be mapped. A Client +wishing to change the state of a window MUST send a _NET_WM_STATE client +message to the root window (see below). The Window Manager MUST keep this +property updated to reflect the current state of the window. + + +The Window Manager should remove the property whenever +a window is withdrawn, but it should leave the property in place when it is +shutting down, e.g. in response to losing ownership of the WM_Sn manager +selection. + + +Rationale: Removing the property upon window withdrawal helps legacy +applications which want to reuse withdrawn windows. Not removing the property +upon shutdown allows the next Window Manager to restore windows to their +previous state. + + +Possible atoms are: + + + +An implementation MAY add new atoms to this list. Implementations +without extensions MUST ignore any unknown atoms, effectively removing +them from the list. These extension atoms MUST NOT start with the prefix +_NET. + + +_NET_WM_STATE_MODAL indicates that this is a modal dialog box. +If the WM_TRANSIENT_FOR hint is set to another toplevel window, the +dialog is modal for that window; if WM_TRANSIENT_FOR is not set or set +to the root window the dialog is modal for its window group. + + +_NET_WM_STATE_STICKY indicates that the Window Manager SHOULD keep the +window's position fixed on the screen, even when the virtual desktop scrolls. + + +_NET_WM_STATE_MAXIMIZED_{VERT,HORZ} indicates that the window is +{vertically,horizontally} maximized. + + +_NET_WM_STATE_SHADED indicates that the window is shaded. + + +_NET_WM_STATE_SKIP_TASKBAR indicates that the window should not be +included on a taskbar. This hint should be requested by the +application, i.e. it indicates that the window by nature is never +in the taskbar. Applications should not set this hint if +_NET_WM_WINDOW_TYPE already conveys the exact nature of the +window. + + +_NET_WM_STATE_SKIP_PAGER indicates that the window should not be +included on a Pager. This hint should be requested by the application, +i.e. it indicates that the window by nature is never in the +Pager. Applications should not set this hint if _NET_WM_WINDOW_TYPE +already conveys the exact nature of the window. + + +_NET_WM_STATE_HIDDEN should be set by the Window Manager to indicate +that a window would not be visible on the screen if its +desktop/viewport were active and its coordinates were within the +screen bounds. The canonical example is that minimized windows should +be in the _NET_WM_STATE_HIDDEN state. Pagers and similar applications +should use _NET_WM_STATE_HIDDEN instead of WM_STATE to decide whether +to display a window in miniature representations of the windows on a +desktop. + + +Implementation note: if an Application asks to toggle +_NET_WM_STATE_HIDDEN the Window Manager should probably just ignore +the request, since _NET_WM_STATE_HIDDEN is a function of some other +aspect of the window such as minimization, rather than an independent +state. + + +_NET_WM_STATE_FULLSCREEN indicates that the window should fill the entire + screen and have no window decorations. For example, a presentation + program would use this hint. + + +_NET_WM_STATE_ABOVE indicates that the window should be on top of most +windows (see for details). + + + +_NET_WM_STATE_BELOW indicates that the window should be below most +windows (see for details). + + + + _NET_WM_STATE_ABOVE and _NET_WM_STATE_BELOW are mainly meant for user + preferences and should not be used by applications e.g. for drawing + attention to their dialogs (the Urgency + hint should be used in that case, see ).' + + + +To change the state of a mapped window, a Client MUST send a _NET_WM_STATE +client message to the root window (window is the respective window, type +_NET_WM_STATE, format 32, l[0]=<the action, as listed below>, +l[1]=<First property to alter>, l[2]=<Second property to alter>). +This message allows two properties to be changed simultaneously, specifically +to allow both horizontal and vertical maximization to be altered together. +l[2] MUST be set to zero if only one property is to be changed. l[0], the +action, MUST be one of: + + + + See also the implementation notes on urgency and fixed size windows. + + + + + _NET_WM_ALLOWED_ACTIONS + + +A list of atoms indicating user operations that the Window Manager supports for +this window. Atoms present in the list indicate allowed actions, atoms not +present in the list indicate actions that are not supported for this window. +The Window Manager MUST keep this property updated to reflect the +actions which are currently "active" or "sensitive" for a window. +Taskbars, Pagers, and other tools use _NET_WM_ALLOWED_ACTIONS to +decide which actions should be made available to the user. + + +Possible atoms are: + + + +An implementation MAY add new atoms to this list. Implementations +without extensions MUST ignore any unknown atoms, effectively removing +them from the list. These extension atoms MUST NOT start with the prefix +_NET. + + +Note that the actions listed here are those that the Window +Manager will honor for this window. The operations must still be +requested through the normal mechanisms outlined in this specification. For +example, _NET_WM_ACTION_CLOSE does not mean that clients can send a +WM_DELETE_WINDOW message to this window; it means that clients can use a +_NET_CLOSE_WINDOW message to ask the Window Manager to do so. + + +Window Managers SHOULD ignore the value of _NET_WM_ALLOWED_ACTIONS when they +initially manage a window. This value may be left over from a previous Window +Manager with different policies. + + +_NET_WM_ACTION_MOVE indicates that the window may be moved around the screen. + + +_NET_WM_ACTION_RESIZE indicates that the window may be resized. +(Implementation note: Window Managers can identify a non-resizable +window because its minimum and maximum size in WM_NORMAL_HINTS will be the same.) + + +_NET_WM_ACTION_MINIMIZE indicates that the window may be iconified. + + +_NET_WM_ACTION_SHADE indicates that the window may be shaded. + + +_NET_WM_ACTION_STICK indicates that the window may have its sticky state +toggled (as for _NET_WM_STATE_STICKY). Note that this state has to do with +viewports, not desktops. + + +_NET_WM_ACTION_MAXIMIZE_HORZ indicates that the window may be maximized horizontally. + + +_NET_WM_ACTION_MAXIMIZE_VERT indicates that the window may be maximized vertically. + + +_NET_WM_ACTION_FULLSCREEN indicates that the window may be brought to + fullscreen state. + + +_NET_WM_ACTION_CHANGE_DESKTOP indicates that the window may be moved between desktops. + + +_NET_WM_ACTION_CLOSE indicates that the window may be closed (i.e. a WM_DELETE_WINDOW +message may be sent). + + + +_NET_WM_STRUT + + +This property is equivalent to a _NET_WM_STRUT_PARTIAL property where all start +values are 0 and all end values are the height or width of the logical screen. +_NET_WM_STRUT_PARTIAL was introduced later than _NET_WM_STRUT, however, so +clients MAY set this property in addition to _NET_WM_STRUT_PARTIAL to ensure +backward compatibility with Window Managers supporting older versions of the +Specification. + + +_NET_WM_STRUT_PARTIAL + + +This property MUST be set by the Client if the window is to reserve space at the +edge of the screen. The property contains 4 cardinals specifying the width of +the reserved area at each border of the screen, and an additional 8 cardinals +specifying the beginning and end corresponding to each of the four struts. The +order of the values is left, right, top, bottom, left_start_y, left_end_y, +right_start_y, right_end_y, top_start_x, top_end_x, bottom_start_x, +bottom_end_x. All coordinates are root window coordinates. The client MAY change +this property at any time, therefore the Window Manager MUST watch for +property notify events if the Window Manager uses this property to assign +special semantics to the window. + + +If both this property and the _NET_WM_STRUT property are set, the Window Manager +MUST ignore the _NET_WM_STRUT property values and use instead the values for +_NET_WM_STRUT_PARTIAL. This will ensure that Clients can safely set both +properties without giving up the improved semantics of the new property. + + +The purpose of struts is to reserve space at the borders of the +desktop. This is very useful for a docking area, a taskbar or a panel, +for instance. The Window Manager should take this reserved area into +account when constraining window positions - maximized windows, for +example, should not cover that area. + + +The start and end values associated with each strut allow areas to be +reserved which do not span the entire width or height of the screen. +Struts MUST be specified in root window coordinates, that is, they are +not relative to the edges of any view port or Xinerama +monitor. + + +For example, for a panel-style Client appearing at the bottom of the +screen, 50 pixels tall, and occupying the space from 200-600 pixels +from the left of the screen edge would set a bottom strut of 50, and +set bottom_start_x to 200 and bottom_end_x to 600. Another example is +a panel on a screen using the Xinerama extension. Assume that the set +up uses two monitors, one running at 1280x1024 and the other to the +right running at 1024x768, with the top edge of the two physical +displays aligned. If the panel wants to fill the entire bottom edge +of the smaller display with a panel 50 pixels tall, it should set a +bottom strut of 306, with bottom_start_x of 1280, and bottom_end_x of +2303. Note that the strut is relative to the screen edge, and not the +edge of the xinerama monitor. + + +Rationale: A simple "do not cover" hint is not enough for dealing with e.g. +auto-hide panels. + + +Notes: An auto-hide panel SHOULD set the strut to be its minimum, hidden size. +A "corner" panel that does not extend for the full length of a screen border +SHOULD only set one strut. + + +_NET_WM_ICON_GEOMETRY + + +This optional property MAY be set by stand alone tools like a taskbar or an +iconbox. It specifies the geometry of a possible icon in case the window is iconified. + + +Rationale: This makes it possible for a Window Manager to display a nice +animation like morphing the window into its icon. + + + + _NET_WM_ICON + + +This is an array of possible icons for the client. This specification does +not stipulate what size these icons should be, but individual desktop +environments or toolkits may do so. The Window Manager MAY scale any of these +icons to an appropriate size. + + +This is an array of 32bit packed CARDINAL ARGB with high byte being A, low +byte being B. The first two cardinals are width, height. Data is in rows, left to +right and top to bottom. + + + + _NET_WM_PID + + +If set, this property MUST contain the process ID of the client owning this +window. This MAY be used by the Window Manager to kill windows which do not +respond to the _NET_WM_PING protocol. + + +If _NET_WM_PID is set, the ICCCM-specified property WM_CLIENT_MACHINE +MUST also be set. While the ICCCM only requests that WM_CLIENT_MACHINE is set + to a string that forms the name of the machine running the client as +seen from the machine running the server conformance to this +specification requires that WM_CLIENT_MACHINE be set to the fully-qualified domain +name of the client's host. + + +See also the implementation notes on killing hung processes. + + + _NET_WM_HANDLED_ICONS + + + This property can be set by a Pager on one of its own toplevel windows + to indicate that the Window Manager need not provide icons for + iconified windows, for example if it is a taskbar and provides buttons + for iconified windows. + + + + + Window Manager Protocols + + _NET_WM_PING + +This protocol allows the Window Manager to determine if the Client is still +processing X events. This can be used by the Window Manager to determine if a +window which fails to close after being sent WM_DELETE_WINDOW has stopped +responding or has stalled for some other reason, such as waiting for user +confirmation. A Client SHOULD indicate that it is willing to participate in +this protocol by listing _NET_WM_PING in the WM_PROTOCOLS property of the +client window. + + +A Window Manager can use this protocol at any time by sending a client message +as follows: + + + +A participating Client receiving this message MUST send it back to the root +window immediately, by setting window = root, and calling XSendEvent. The +Client MUST NOT alter the timestamp, as this can be used by the Window Manager +to uniquely identify the ping. + + +The Window Manager MAY kill the Client (using _NET_WM_PID) if it fails to +respond to this protocol within a reasonable time. + + +See also the implementation notes on killing hung processes. + + + + + Implementation notes + + 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. + + + + 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). + + + + 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 behavior is +pretty standard for many toolkits and window managers, and is extremely +unlikely to break anything, it seems reasonable to document it as standard. + + + + Urgency + +Windows expecting immediate user action should indicate this using the +urgency bit in the WM_HINTS.flags property, as defined in the ICCCM. + + + + 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. + + + + Pagers and Taskbars + + This specification attempts to make reasonable provisions for window + manager 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 communicate with the Window Manager using further, + window manager specific hints, or some other means. + + + Pagers should decide whether to show a miniature version of a + window using the following guidelines: + + + + If either _NET_WM_STATE_SKIP_PAGER or + _NET_WM_STATE_HIDDEN are set on a window, then the + pager should not show that window. + + + + + The pager may choose not to display windows with + certain semantic types; this spec has no + recommendations, but common practice is to avoid + displaying _NET_WM_WINDOW_TYPE_DOCK for example. + + + + + If the _NET_WM_STATE_SKIP_PAGER and + _NET_WM_STATE_HIDDEN hints are not present, and the + Window Manager claims to support _NET_WM_STATE_HIDDEN, + then the window should be shown if it's in either + NormalState or IconicState. + + + + + For Window Managers that do not support + _NET_WM_STATE_HIDDEN, the pager should + not show windows in IconicState. These Window + Managers are probably using an older version + of this specification. + + + + + + + Window Geometry + +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: + + + +Window Managers MUST honor the win_gravity field of WM_NORMAL_HINTS +for both MapRequest and ConfigureRequest events +(ICCCM Version 2.0, §4.1.2.3 and §4.1.5) + + +When generating synthetic ConfigureNotify events, the position given +MUST be the top-left corner of the client window in relation to the +origin of the root window (i.e., ignoring win_gravity) +(ICCCM Version 2.0, §4.2.3) + + +Window Managers maintain a reference point for each client window and place +the window relative to this reference point depending on the window's +win_gravity as follows: + + + + + + win_gravity: + placed at the reference point + + + StaticGravity + the left top corner of the client window + + + NorthWestGravity + the left top corner of the frame window + + + NorthGravity + the center of the frame window's top side + + + NorthEastGravity + the right top corner of the frame window + + + EastGravity + the center of the frame window's right side + + + SouthEastGravity + the right bottom corner of the frame window + + + SouthGravity + the center of the frame window's bottom side + + + SouthWestGravity + the left bottom corner of the frame window + + + WestGravity + the center of the frame window's left side + + + CenterGravity + the center of the frame window + + + + + + +Applications are free to change their win_gravity setting at any time. + + +If an Application changes its win_gravity then the Window Manager should +adjust the reference point, so that the client window will not move as the +result. For example if the Application's win_gravity was NorthWestGravity and +reference point was at the top-left corner of the frame window, then after +change of win_gravity to SouthEastGravity the reference point should be +adjusted to point to the lower-right corner of the frame. + + + +Changing the win_gravity for a single configure request and back afterwards is +unlikely to work as intended, due to a race condition. The window manager sees +a property notify for WM_NORMAL_HINTS, followed by the configure request, +followed by another property notify for WM_NORMAL_HINTS. By the time the +window manager gets around to request the changed WM_NORMAL_HINTS in response +to the first property notify, the server may have already processed the second +property change. + + +If the window manager supports it, applications should use +_NET_MOVERESIZE_WINDOW with a specified gravity to avoid this problem. + + + + +If the Application requests a new position (x, y) (and possibly also a +new size), the Window Manager calculates a new reference point (ref_x, ref_y), +based on the client window's (possibly new) size (width, height), border +width (bw) and win_gravity as explained in the table below. + + +The Window Manager will use the new reference point until the next request for +a new position. + + + + + + win_gravity: + ref_x: + ref_y: + + + StaticGravity + x + y + + + NorthWestGravity + x-bw + y-bw + + + NorthGravity + x+(width/2) + y-bw + + + NorthEastGravity + x+width+bw + y-bw + + + EastGravity + x+width+bw + y+(height/2) + + + SouthEastGravity + x+width+bw + y+height+bw + + + SouthGravity + x+(width/2) + y+height+bw + + + SouthWestGravity + x-bw + y+height+bw + + + WestGravity + x-bw + y+(height/2) + + + CenterGravity + x+(width/2) + y+(height/2) + + + + + + +If an Application requests just a new size, its reference point does not +move. So for example if client window has win_gravity SouthEastGravity and +is resized, the bottom right corner of its frame will not move but instead +the top left corner will be adjusted by the difference in size. + + +When calculating the reference point at the time of initial placement, +the Window Manager should take the initial window's size into consideration, +as if it was the frame for this window. + + + + + 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. + + + + 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 is usually set by calling XSetWMProperties(). The hostname for the current host can be be retrieved using gethostname(), when gethostname() +is not available on the platform implementors may use the value of the +nodename field of struct utsname as returned by uname(). Note also that the value of WM_CLIENT_MACHINE is not guaranteed +to be a fully fully-qualified domain name of the host. An example of how to +retrieve the hostname: + + + = maxlen) len = maxlen - 1; + strncpy (buf, name.nodename, len); + buf[len] = '\0'; + + return len; +#endif +} +]]> + + + + + Stacking order + + To obtain good interoperability between different Desktop Environments, + the following layered stacking order is recommended, from the bottom: + + windows of type _NET_WM_TYPE_DESKTOP + windows having state _NET_WM_STATE_BELOW + windows not belonging in any other layer + windows of type _NET_WM_TYPE_DOCK (unless they have + state _NET_WM_TYPE_BELOW) and windows having state + _NET_WM_STATE_ABOVE + focused windows having state + _NET_WM_STATE_FULLSCREEN + + + + Windows that are transient for another window should be kept + above this window. + + + The window manager may choose to put some windows in different + stacking positions, for example to allow the user to bring currently + a active window to the top and return it back when the window looses + focus. + + + + + References + + + [UTF8] + + + F. Yergeau,"UTF-8, a transformation format of ISO 10646", RFC 2279 + + + + + [ICCCM] + + + David Rosenthal and Stuart W. Marks, "Inter-Client Communication + Conventions Manual (Version 2.0)", X Consortium Standard, X Version 11, + Release 6.3 + + + + + + + Copyright + +Copyright (C) 2000-2003 See Contributors List + + +Permission is hereby granted, free of charge, to any person +obtaining a copy of this software and associated documentation +files (the "Software"), to deal in the Software without +restriction, including without limitation the rights to use, +copy, modify, merge, publish, distribute, sublicense, and/or +sell copies of the Software, and to permit persons to whom +the Software is furnished to do so, subject to the following +conditions: + + +The above copyright notice and this permission notice shall +be included in all copies or substantial portions of the +Software. + + +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY +KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE +WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE +AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS +BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, +WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING +FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE +OR OTHER DEALINGS IN THE SOFTWARE. + + + + Contributors + + Sasha Vasko + Bradley T. Hughes + Dominik Vogt + Havoc Pennington + Jeff Raven + Jim Gettys + John Harper + Julian Adams + Matthias Ettrich + Micheal Rogers + Nathan Clemons + Tim Janik + Tomi Ollila + Sam Lantinga + The Rasterman + Paul Warren + Owen Taylor + Marko Macek + Greg Badros + Matthias Clasen + David Rosenthal + Lubos Lunak + Rob Adams + + + Change history + + Changes since 1.2 + + +Added new property _NET_WM_STRUT_PARTIAL to allow partial-width struts. + + +Rewrote the implementation notes on "Window Movement", retitled it +to "Window Geometry". + + +Rewrote the implementation notes on "Urgency", making it clear that +the hint is not just about dialogs. + + +Fixed the specification of the X and Y members of _NET_DESKTOP_LAYOUT +and renamed them to columns and row for clarity. + + +Change the description of _NET_WM_STATE_MODAL to no longer require apps to +break the ICCCM for group-modal windows, but still support the +WM_TRANSIENT_FOR=root dialect. + + + + + Changes since 1.1 + + + Changed WM_CLIENT_NAME(STRING) from suggested to required for _NET_WM_PID. + + + Specification and sample code for the content of WM_CLIENT_NAME(STRING). + + + Added _NET_WM_WINDOW_TYPE_SPLASH, _NET_WM_WINDOW_TYPE_UTILITY. + + + Added _NET_WM_STATE_FULLSCREEN. + + + Added _NET_WM_ALLOWED_ACTIONS. + + + Added _NET_WM_STATE_HIDDEN and clarified purpose of + _NET_WM_STATE_SKIP_PAGER and _NET_WM_STATE_SKIP_TASKBAR. Changed + section on virtual desktop implementation to suggest ICCCM compliance + regarding IconicState, using _NET_WM_STATE_HIDDEN to avoid confusion. + Added implementation note for pagers on when to display a window. + + + Added button field and new directions for keyboard-initiated actions + to the _NET_WM_MOVERESIZE message. + + + Added advice on removing _NET_WM_STATE and _NET_WM_DESKTOP when a window + is withdrawn. + + + Added _NET_DESKTOP_LAYOUT to allow a Pager to specify inter-desktop geometry. + + + Added _NET_SHOWING_DESKTOP. + + + Added _NET_WM_STATE_ABOVE and _NET_WM_STATE_BELOW and a recommended layered + stacking order. + + + Added _NET_MOVERESIZE_WINDOW. + + + Improve markup of citations. + + + Explain _NET_DESKTOP_GEOMETRY and _NET_WM_HANDLED_ICONS in more detail and + improve the explanation of WM_CLIENT_MACHINE in + . + + + Add Lubos Lunak to the list of contributors. + + + + + Changes since 1.0 + + +Fix doctype, add author info, update data. + + +Change specification description wording to be more inclusive, and to reflect the joint nature of the specification. + + +Fix miscellaneous typographical, grammar and spelling errors. + + +Clarified _NET_SUPPORTED to include ALL atoms, not just the property names. + + +Various corrections to use of MUST and SHOULD. + + +Fix problem in _NET_WM_ICON where 'bytes' should have been 'cardinals' + + +Replaced ISO-8559-1 characters with entities. + + + + + Changes since 1.0pre5 + + +Change history moved to end. + + +UTF-8 Reference updated. + + +Window Gravity information updated. + + +Copyright Added. + + +Minor typo corrections. + + + + + Changes since 1.0pre4 + + +Clarified the interpretation of client-provided geometries on large desktops. + + +Added more explanation for _NET_DESKTOP_NAMES. + + +Added _NET_WM_ICON_NAME and _NET_WM_VISIBLE_ICON_NAME. + + +Tried to improve the wording of _NET_WM_STRUT explanation. + + +Changed _NET_WORKAREA to an array of viewport-relative geometries. + + +Updated list of dependent properties for _NET_NUMBER_OF_DESKTOPS +to include _NET_WORKAREA and _NET_DESKTOP_VIEWPORT. + + +Tidied formatting of all client messages. + + + + + Changes since 1.0pre3 + + +Added information about common non-ICCCM features. + + +Added explanation of sending messages to the root window. + + +Removed XA_ prefix from type names. + + +Clarified that mapping order refers to inital mapping +and specify the directions of both orders. + + +Clarified that desktops have a common size specified by _NET_DESKTOP_GEOMETRY. + + +Rewrote explanation of _NET_DESKTOP_VIEWPORT. + + +Tidied formatting of _NET_CURRENT_DESKTOP. + + +Replaced window handle by window ID. + + +Tidied formatting of _NET_WORKAREA. + + +Rewrote the motivation for _NET_VIRTUAL_ROOTS. + + +Added advice on Pointer grabs to _NET_WM_MOVERESIZE. + + +Fixed typos in _NET_WM_STATE. + + +Added _NET_WM_STATE_SKIP_PAGER. + + +Tidied formatting of _NET_WM_STRUT. + + +Tidied formatting of _NET_WM_ICON_GEOMETRY. + + + + + Changes since 1.0pre2 + + +_NET_SET_NUMBER_OF_DESKTOPS -> _NET_NUMBER_OF_DESKTOPS for consistency. + + +_NET_WM_VISIBLE_NAME_STRING -> _NET_WM_VISIBLE_NAME for consistency. + + +_NET_WM_STATE: added explanation of permitted extensions. Added explanation of +being set / not set. + + +Spellchecked, corrected various typos. + + +UTF8 -> UTF-8 for consistency. + + +added references to the ICCCM an UTF-8 (incomplete). + + +added data and event formats where missing. + + +clarified _NET_SUPPORTING_WM_CHECK. + + +fixed formatting of _NET_CLOSE_WINDOW message. + + + + + Changes since 1.0pre1 + + +Removed implementation note concerning Gnome's (potential) file manager behavior. + + +The Window Movement section of the implementation notes has been revised. + + + + + Changes since 1.9f + + +Revised revision number for first accepted release 1.9XX -> 1.0preXX. + + +Prerequisites for adoption of this specification added. + + +Tidied formatting of _NET_CURRENT_DESKTOP for consistency. + + +Tidied formatting of _NET_ACTIVE_WINDOW for consistency. Removed doubled text. + + +Tidied formatting of _NET_WM_DESKTOP for consistency. + + +Killing Hung Processes implementation note added. _NET_WM_PID and _NET_WM_PING now link to this. + + +Clarified x_root and y_root meaning for _NET_WM_MOVERESIZE. + + +Added contributor list. + + + + + Changes since 1.9e + + +Added _NET_WM_VISIBLE_NAME_STRING + + +Removed ambiguity from _NET_NUMBER_OF_DESKTOPS and _NET_DESKTOP_NAMES in combination. + + +Set _NET_WM_MOVERESIZE format to 32 for consistency. + + +Removed _NET_PROPERTIES. + + +Removed comment from _NET_WM_MOVERESIZE. + + + + + Changes since 1.9d + + +Added _NET_VIRTUAL_ROOTS + + +Added note about ICCCM compliant window moves. + + +Added _NET_WM_HANDLED_ICONS + + +Added _NET_SUPPORTING_WM_CHECK + + +Removed degrees of activation + + + + + Changes since 1.9c + + + +Removed packaging of hints into 2 X properties. Jim Gettys points out that the +performance gains of fewer round trips can be better achieved using Xlib +routines. + + + + +Clarified that _NET_DESKTOP_VIEWPORT is in pixels + + + + +_NET_DESKTOP_VIEWPORT is now an array, one for each desktop, to allow for +different active viewports on different desktops + + + + +_NET_WM_STRUT now only applies on desktops on which the client is visible + + + + +Introduced RFC 2119 language, and attempted to clarify the roles of the Window +Manager, Pagers and Applications + + + + +Added _NET_WM_NAME + + + + +_NET_DESKTOP_NAMES now in UTF8 + + + + +Desktops now start from 0 + + + + +Added _NET_WM_PID + + + + +Added _NET_WM_PING protocol + + + + +Added _NET_WM_STATE_SKIP_TASKBAR + + + + + + + Changes since 1.9b + + Removed _NET_NUMBER_OF_DESKTOPS client message, as it overlaps unnecessarily with _NET_{INSERT/DELETE}_DESKTOP. + + Replaced _NET_WM_LAYER and _NET_WM_HINTS with _NET_WM_WINDOW_TYPE functional hint. + Changed _NET_WM_STATE to a list of atoms, for extensibility. + Expanded description of _NET_WORKAREA and _NET_WM_STRUT. + Removed _NET_WM_SIZEMOVE_NOTIFY protocol. + Added degrees of activation to _NET_ACTIVE_WINDOW client message + Added _NET_WM_ICON + My comments are in [[ ]]. Comments from Marko's draft are in [[MM: ]] + + + +
+ -- cgit v1.2.3-54-g00ecf From ef233046798d88af945ea8aaaded684148072216 Mon Sep 17 00:00:00 2001 From: lanius Date: Wed, 9 Jul 2003 14:02:43 +0000 Subject: changed from sgml to xml --- wm-spec/wm-spec.xml | 25 +++++++++++++------------ 1 file changed, 13 insertions(+), 12 deletions(-) diff --git a/wm-spec/wm-spec.xml b/wm-spec/wm-spec.xml index 3019eb7..0f483fe 100644 --- a/wm-spec/wm-spec.xml +++ b/wm-spec/wm-spec.xml @@ -1,6 +1,7 @@ - - + + ]>
@@ -20,7 +21,7 @@ This is &version; of the Extended Window Manager Hints (EWMH) spec, updated &date;. The canonical home for this document is http://www.freedesktop.org, +url="http://www.freedesktop.org/standards/wm-spec/">http://www.freedesktop.org, which also contains directions for reporting bugs or contributing to future versions. @@ -756,7 +757,7 @@ _NET_WM_VISIBLE_NAME, UTF8_STRING If the Window Manager displays a window name other than _NET_WM_NAME the Window Manager MUST set this to the title displayed in UTF-8 encoding. -Rationale: This property is for Window Managers that display a title different from the _NET_WM_NAME or WM_NAME of the window (i.e. xterm <1>, xterm <2>, ... is shown, but _NET_WM_NAME / WM_NAME is still xterm for each window) thereby allowing Pagers to display the same title as the Window Manager. +Rationale: This property is for Window Managers that display a title different from the _NET_WM_NAME or WM_NAME of the window (i.e. xterm <1>, xterm <2>, ... is shown, but _NET_WM_NAME / WM_NAME is still xterm for each window) thereby allowing Pagers to display the same title as the Window Manager. @@ -1664,8 +1665,8 @@ int net_get_hostname (char *buf, size_t maxlen) focus. - - + + References @@ -1687,8 +1688,8 @@ int net_get_hostname (char *buf, size_t maxlen) - - + + Copyright Copyright (C) 2000-2003 See Contributors List @@ -1718,8 +1719,8 @@ WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. - - + + Contributors Sasha Vasko @@ -1746,7 +1747,7 @@ OR OTHER DEALINGS IN THE SOFTWARE. Lubos Lunak Rob Adams - + Change history Changes since 1.2 -- cgit v1.2.3-54-g00ecf From 224ebabfe37ddcce3eb6c75930481db039574f8c Mon Sep 17 00:00:00 2001 From: lunakl Date: Tue, 29 Jul 2003 18:03:20 +0000 Subject: Default values for (yet) unused field in client messages (http://mail.gnome.org/archives/wm-spec-list/2003-May/msg00014.html). --- wm-spec/wm-spec.xml | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/wm-spec/wm-spec.xml b/wm-spec/wm-spec.xml index 0f483fe..d6a1c8b 100644 --- a/wm-spec/wm-spec.xml +++ b/wm-spec/wm-spec.xml @@ -319,6 +319,7 @@ _NET_NUMBER_OF_DESKTOPS message_type = _NET_NUMBER_OF_DESKTOPS format = 32 data.l[0] = new_number_of_desktops + other data.l[] elements = 0 ]]> The Window Manager is free to honor or reject this request. If the request is honored _NET_NUMBER_OF_DESKTOPS MUST be set to the new number of desktops, _NET_VIRTUAL_ROOTS MUST be set to store the new number of desktop virtual root window IDs and _NET_DESKTOP_VIEWPORT and _NET_WORKAREA must also be changed accordingly. The _NET_DESKTOP_NAMES property MAY remain unchanged. @@ -348,6 +349,7 @@ _NET_DESKTOP_GEOMETRY format = 32 data.l[0] = new_width data.l[1] = new_height + other data.l[] elements = 0 ]]> The Window Manager MAY choose to ignore this message, in which case _NET_DESKTOP_GEOMETRY property will remain unchanged. @@ -373,6 +375,7 @@ _NET_DESKTOP_VIEWPORT format = 32 data.l[0] = new_vx data.l[1] = new_vy + other data.l[] elements = 0 ]]> The Window Manager MAY choose to ignore this message, in which case _NET_DESKTOP_VIEWPORT property will remain unchanged. @@ -392,6 +395,7 @@ _NET_CURRENT_DESKTOP message_type = _NET_CURRENT_DESKTOP format = 32 data.l[0] = new_index + other data.l[] elements = 0 ]]> _NET_DESKTOP_NAMES _NET_WORKAREA The Window Manager may choose to ignore this client message. @@ -637,6 +643,7 @@ _NET_CLOSE_WINDOW message_type = _NET_CLOSE_WINDOW format = 32 data.l[0] = 0 /* may be used later */ + other data.l[] elements = 0 ]]> The Window Manager MUST then attempt to close the window specified. @@ -693,6 +700,7 @@ _NET_WM_MOVERESIZE data.l[1] = y_root data.l[2] = direction data.l[3] = button + other data.l[] elements = 0 ]]> This message allows Clients to initiate window movement or @@ -818,6 +826,7 @@ _NET_WM_DESKTOP message_type = _NET_WM_DESKTOP format = 32 data.l[0] = new_desktop + other data.l[] elements = 0 ]]> The Window Manager MUST keep this property updated on all windows. @@ -1282,6 +1291,7 @@ message_type = WM_PROTOCOLS format = 32 data.l[0] = _NET_WM_PING data.l[1] = timestamp +other data.l[] elements = 0 ]]> A participating Client receiving this message MUST send it back to the root -- cgit v1.2.3-54-g00ecf From 25ad2007e9601e32167d2f546394b07af3018d40 Mon Sep 17 00:00:00 2001 From: lunakl Date: Tue, 29 Jul 2003 18:03:54 +0000 Subject: Updates for _NET_WM_PING. --- wm-spec/wm-spec.xml | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/wm-spec/wm-spec.xml b/wm-spec/wm-spec.xml index d6a1c8b..b789d51 100644 --- a/wm-spec/wm-spec.xml +++ b/wm-spec/wm-spec.xml @@ -1291,13 +1291,17 @@ message_type = WM_PROTOCOLS format = 32 data.l[0] = _NET_WM_PING data.l[1] = timestamp +data.l[2] = the respective client window other data.l[] elements = 0 ]]> A participating Client receiving this message MUST send it back to the root -window immediately, by setting window = root, and calling XSendEvent. The -Client MUST NOT alter the timestamp, as this can be used by the Window Manager -to uniquely identify the ping. +window immediately, by setting window = root, and calling XSendEvent with +the same event mask like all other root window messages in this specification use. +The Client MUST NOT alter any field in the event other than the window. This +includes all 5 longs in the data.l[5] array. The Window Manager can uniquely +identify the ping by the timestamp and the data.l[2] field if necessary. +Note that some older clients may not preserve data.l[2] through data.l[4]. The Window Manager MAY kill the Client (using _NET_WM_PID) if it fails to -- cgit v1.2.3-54-g00ecf From 231908869bd89e83ff73129d9cbdf040dce1cf4c Mon Sep 17 00:00:00 2001 From: lunakl Date: Tue, 29 Jul 2003 18:04:19 +0000 Subject: _NET_WM_USER_TIME --- wm-spec/wm-spec.xml | 32 ++++++++++++++++++++++++++++++++ 1 file changed, 32 insertions(+) diff --git a/wm-spec/wm-spec.xml b/wm-spec/wm-spec.xml index b789d51..05613c9 100644 --- a/wm-spec/wm-spec.xml +++ b/wm-spec/wm-spec.xml @@ -1266,6 +1266,38 @@ _NET_WM_HANDLED_ICONS for iconified windows. + _NET_WM_USER_TIME + + +This property contains the XServer time at which last user activity in this +window took place. + + +Clients should keep the last timestamp from user interaction. and set +this timestamp in this property on every new toplevel window before mapping it. +A client that only deals with core events, might, for example, use the +timestamp of the last KeyPress, ButtonPress, or ButtonRelease +event. KeyRelease events should not generally be considered to +be user interaction, because an application may receive KeyRelease +events from global keybindings. Clients should start setting the property +only after receiving the first event from user interaction, they shouldn't set +it before receiving first input event. The special value of zero on a newly +mapped window means that the window shouldn't initially get focus after being mapped. + + +If the client has the active window, it should also update this property +on the window whenever there's user activity. + + +Rationale: This property allows a Window Manager to alter the focus, +stacking, and/or placement behavior of windows when they are +mapped depending on whether the new window was created by a user +action or is a "pop-up" window activated by a timer or some other +event. + + Window Manager Protocols -- cgit v1.2.3-54-g00ecf From 8460067c8deffa67f7b811d5cd8f207032ec12f3 Mon Sep 17 00:00:00 2001 From: lunakl Date: Tue, 29 Jul 2003 18:08:38 +0000 Subject: Changelog for added things. --- wm-spec/wm-spec.xml | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/wm-spec/wm-spec.xml b/wm-spec/wm-spec.xml index 05613c9..0e03aa5 100644 --- a/wm-spec/wm-spec.xml +++ b/wm-spec/wm-spec.xml @@ -1818,6 +1818,15 @@ Change the description of _NET_WM_STATE_MODAL to no longer require apps to break the ICCCM for group-modal windows, but still support the WM_TRANSIENT_FOR=root dialect. + +Specified that (yet) unused fields in client messages must be set to 0. + + +_NET_WM_PING message now has the client window identified in data.l[2] field. + + +Added _NET_WM_USER_TIME to detect user activity in windows. + -- cgit v1.2.3-54-g00ecf From d19973809ebcc6a2acb0e1c8ca441b7a6a4ef463 Mon Sep 17 00:00:00 2001 From: llunak Date: Tue, 16 Dec 2003 13:56:02 +0000 Subject: Support for focus stealing prevention (http://mail.gnome.org/archives/wm-spec-list/2003-October/msg00039.html). --- wm-spec/wm-spec.xml | 93 ++++++++++++++++++++++++++++++++++++++++++++++++++--- 1 file changed, 88 insertions(+), 5 deletions(-) diff --git a/wm-spec/wm-spec.xml b/wm-spec/wm-spec.xml index 0e03aa5..cfcc8b3 100644 --- a/wm-spec/wm-spec.xml +++ b/wm-spec/wm-spec.xml @@ -436,9 +436,26 @@ _NET_ACTIVE_WINDOW window = window to activate message_type = _NET_ACTIVE_WINDOW format = 32 - data.l[0] = 0 /* may be used later */ + data.l[0] = source indication + data.l[1] = timestamp + data.l[2] = requestor's currently active window, 0 if none other data.l[] elements = 0 ]]> + +Source indication should be 1 when the request comes from an application, and 2 +when it comes from a pager. Clients using older version of this spec use 0 +as source indication, see for details. +The timestamp is Client's last user activity timestamp (see _NET_WM_USER_TIME) +at the time of the request, and the currently active window +is the Client's active toplevel window, if any (the Window Manager may +be e.g. more likely to obey the request if it will mean transferring +focus from one active window to another). + + +Depending on the information provided with the message, the Window Manager may +decide to refuse the request (either completely ignore it, or e.g. use +_NET_WM_STATE_DEMANDS_ATTENTION). + _NET_WORKAREA + _NET_RESTACK_WINDOW + + + Pagers wanting to restack a window SHOULD send a _NET_CLOSE_WINDOW client + message request to the root window: + + + + This request is similar to ConfigureRequest with CWSibling and CWStackMode flags. It should be used only by pagers, + applications can use normal ConfigureRequests. The source indication field should be therefore set to 1, + see for details. + + + Rationale: A Window Manager may put restrictions on configure requests from applications, for example it may + under some conditions refuse to raise a window. This request makes it clear it comes from a pager or similar + tool, and therefore the Window Manager should always obey it. + + Application Window Properties @@ -944,6 +990,7 @@ _NET_WM_STATE_HIDDEN, ATOM _NET_WM_STATE_FULLSCREEN, ATOM _NET_WM_STATE_ABOVE, ATOM _NET_WM_STATE_BELOW, ATOM +_NET_WM_STATE_DEMANDS_ATTENTION, ATOM ]]> An implementation MAY add new atoms to this list. Implementations @@ -1022,6 +1069,15 @@ windows (see for details). hint should be used in that case, see ).' + +_NET_WM_STATE_DEMANDS_ATTENTION indicates that some action in or with the window +happened. For example, it may be set by the Window Manager if the window requested +activation but the Window Manager refused it, or the application may set it if it +finished some work. This state may be set by both the Client and +the Window Manager. It should be unset by the Window Manager when it decides +the window got the required attention (usually, that it got activated). + + To change the state of a mapped window, a Client MUST send a _NET_WM_STATE client message to the root window (window is the respective window, type @@ -1278,10 +1334,11 @@ window took place. Clients should keep the last timestamp from user interaction. and set this timestamp in this property on every new toplevel window before mapping it. A client that only deals with core events, might, for example, use the -timestamp of the last KeyPress, ButtonPress, or ButtonRelease -event. KeyRelease events should not generally be considered to -be user interaction, because an application may receive KeyRelease -events from global keybindings. Clients should start setting the property +timestamp of the last KeyPress or ButtonPress event. ButtonRelease and KeyRelease +events should not generally be considered to be user interaction, because an application +may receive KeyRelease events from global keybindings, and generally release events +may have later timestamp than actions that were triggered by the matching press events. +Clients should start setting the property only after receiving the first event from user interaction, they shouldn't set it before receiving first input event. The special value of zero on a newly mapped window means that the window shouldn't initially get focus after being mapped. @@ -1711,6 +1768,22 @@ int net_get_hostname (char *buf, size_t maxlen) focus. + + + Source indication in requests + + Some requests from Clients include type of the Client, for example + the _NET_ACTIVE_WINDOW message. Currently the types can be + 1 for normal applications, and 2 for pagers and other Clients + that represent direct user actions (the Window Manager may decide + to treat requests from applications differently than requests + that are result of direct user actions). + Clients that support only older version of this spec will have 0 + as their source indication, thus not specifying their source at all. + This also may mean that some of the fields in the message comply + only with the older specification version. + + References @@ -1799,6 +1872,16 @@ OR OTHER DEALINGS IN THE SOFTWARE. Changes since 1.2 +Added new state _NET_WM_STATE_DEMANDS_ATTENTION. + + +Added timestamp, source indication and requestor's active window +fields to the _NET_ACTIVE_WINDOW message. + + +Added _NET_RESTACK_WINDOW message. + + Added new property _NET_WM_STRUT_PARTIAL to allow partial-width struts. -- cgit v1.2.3-54-g00ecf From 71ac2cb2b4ffc7a5190e970456e27ec6a3b7ec40 Mon Sep 17 00:00:00 2001 From: llunak Date: Wed, 7 Jan 2004 09:57:48 +0000 Subject: Frame extents from Thomas Fitzsimmons . (http://mail.gnome.org/archives/wm-spec-list/2003-December/msg00032.html) --- wm-spec/wm-spec.xml | 46 +++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 45 insertions(+), 1 deletion(-) diff --git a/wm-spec/wm-spec.xml b/wm-spec/wm-spec.xml index cfcc8b3..3b31964 100644 --- a/wm-spec/wm-spec.xml +++ b/wm-spec/wm-spec.xml @@ -790,7 +790,36 @@ _NET_CLOSE_WINDOW tool, and therefore the Window Manager should always obey it. - + _NET_REQUEST_FRAME_EXTENTS + + +A Client whose window has not yet been mapped can request of the +Window Manager an estimate of the frame extents it will be given upon +mapping. To retrieve such an estimate, the Client MUST send a +_NET_REQUEST_FRAME_EXTENTS message to the root window. The Window +Manager MUST respond by estimating the prospective frame extents and +setting the window's _NET_FRAME_EXTENTS property accordingly. The +Client MUST handle the resulting _NET_FRAME_EXTENTS PropertyNotify +event. So that the Window Manager has a good basis for estimation, +the Client MUST set any window properties it intends to set +before sending this message. The Client MUST be able to cope +with imperfect estimates. + + +Rationale: A client cannot calculate the dimensions of its window's +frame before the window is mapped, but some toolkits need this +information. Asking the window manager for an estimate of the extents +is a workable solution. The estimate may depend on the current theme, +font sizes or other window properties. The client can track changes +to the frame's dimensions by listening for _NET_FRAME_EXTENTS +PropertyNotify events. + + + Application Window Properties _NET_WM_NAME @@ -1355,6 +1384,16 @@ action or is a "pop-up" window activated by a timer or some other event. + _NET_FRAME_EXTENTS + + +The Window Manager MUST set _NET_FRAME_EXTENTS to the extents of the +window's frame. left, right, top and bottom are widths of the +respective borders added by the Window Manager. + + Window Manager Protocols @@ -1865,6 +1904,7 @@ OR OTHER DEALINGS IN THE SOFTWARE. David Rosenthal Lubos Lunak Rob Adams + Thomas Fitzsimmons Change history @@ -1872,6 +1912,10 @@ OR OTHER DEALINGS IN THE SOFTWARE. Changes since 1.2 +Added _NET_REQUEST_FRAME_EXTENTS and _NET_FRAME_EXTENTS to allow a +client to retrieve its window's frame extents. + + Added new state _NET_WM_STATE_DEMANDS_ATTENTION. -- cgit v1.2.3-54-g00ecf From e8f1feb4a3bb39681ba2666ac2a9dd48cf21ff4c Mon Sep 17 00:00:00 2001 From: llunak Date: Thu, 29 Jan 2004 13:19:58 +0000 Subject: Oops, _NET_RESTACK_WINDOW had _NET_CLOSE_WINDOW in some places (copy&paste error). --- wm-spec/wm-spec.xml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/wm-spec/wm-spec.xml b/wm-spec/wm-spec.xml index 3b31964..2add3bd 100644 --- a/wm-spec/wm-spec.xml +++ b/wm-spec/wm-spec.xml @@ -766,13 +766,13 @@ _NET_WM_MOVERESIZE _NET_RESTACK_WINDOW ]]> - Pagers wanting to restack a window SHOULD send a _NET_CLOSE_WINDOW client + Pagers wanting to restack a window SHOULD send a _NET_RESTACK_WINDOW client message request to the root window: Date: Fri, 28 May 2004 16:23:09 +0000 Subject: Add _NET_WM_SYNC_REQUEST --- wm-spec/wm-spec.xml | 56 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 56 insertions(+) diff --git a/wm-spec/wm-spec.xml b/wm-spec/wm-spec.xml index 2add3bd..7d39f80 100644 --- a/wm-spec/wm-spec.xml +++ b/wm-spec/wm-spec.xml @@ -1438,6 +1438,57 @@ respond to this protocol within a reasonable time. See also the implementation notes on killing hung processes. + _NET_WM_SYNC_REQUEST + +This protocol uses the XSync extension (see the +protocol specification and +the library documentation) to let client and window manager +synchronize the repaint of the window manager frame and the client +window. A client indicates that it is willing to participate in the +protocol by listing _NET_WM_SYNC_REQUEST in the WM_PROTOCOLS property +of the client window and storing the XID of an XSync counter in the +property _NET_WM_SYNC_REQUEST_COUNTER. The initial value of this +counter is not defined by this specification. + + +A window manager uses this protocol by preceding a ConfigureNotify +event sent to a client by a client message as follows: + + + + +After receiving one or more such message/ConfigureNotify pairs, and +having handled all repainting associated with the ConfigureNotify +events, the client MUST set the _NET_WM_SYNC_REQUEST_COUNTER to the 64 +bit number indicated by the data.l[2] and data.l[3] fields of the last +client message received. + + +By using either the Alarm or the Await mechanisms of the XSync +extension, the window manager can know when the client has finished +handling the ConfigureNotify events. The window manager SHOULD not +resize the window faster than the client can keep up. + + +The update request number in the client message is determined by the +window manager, but is generally intended to be incremented by one for +each message sent. Since the initial value of the XSync counter is not +defined by this specification, the window manager MAY set the value of +the XSync counter at any time, and MUST do so when it first manages a +new window. + @@ -1905,12 +1956,17 @@ OR OTHER DEALINGS IN THE SOFTWARE. Lubos Lunak Rob Adams Thomas Fitzsimmons + Søren Sandmann Change history Changes since 1.2 + +Added _NET_WM_SYNC_REQUEST to allow synchronized repaint of +application window and window manager frame during opaque resize. + Added _NET_REQUEST_FRAME_EXTENTS and _NET_FRAME_EXTENTS to allow a client to retrieve its window's frame extents. -- cgit v1.2.3-54-g00ecf From 869919fafb3782728ed373b5891cd8adcc85d263 Mon Sep 17 00:00:00 2001 From: andersca Date: Wed, 2 Jun 2004 11:26:51 +0000 Subject: Add timestamp to _NET_CLOSE_WINDOW --- wm-spec/wm-spec.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/wm-spec/wm-spec.xml b/wm-spec/wm-spec.xml index 7d39f80..a73dbbc 100644 --- a/wm-spec/wm-spec.xml +++ b/wm-spec/wm-spec.xml @@ -659,7 +659,7 @@ _NET_CLOSE_WINDOW window = window to close message_type = _NET_CLOSE_WINDOW format = 32 - data.l[0] = 0 /* may be used later */ + data.l[0] = timestamp other data.l[] elements = 0 ]]> -- cgit v1.2.3-54-g00ecf From eb431cd87460381fd9e99c30279b4dcb778538dd Mon Sep 17 00:00:00 2001 From: sandmann Date: Sun, 20 Jun 2004 11:25:11 +0000 Subject: Clarify the the window manager must not send a 0 sync request --- wm-spec/wm-spec.xml | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/wm-spec/wm-spec.xml b/wm-spec/wm-spec.xml index a73dbbc..929dc17 100644 --- a/wm-spec/wm-spec.xml +++ b/wm-spec/wm-spec.xml @@ -1483,11 +1483,12 @@ resize the window faster than the client can keep up. The update request number in the client message is determined by the -window manager, but is generally intended to be incremented by one for -each message sent. Since the initial value of the XSync counter is not -defined by this specification, the window manager MAY set the value of -the XSync counter at any time, and MUST do so when it first manages a -new window. +window manager subject to the restriction that it MUST NOT be 0. The +number is generally intended to be incremented by one for each message +sent. Since the initial value of the XSync counter is not defined by +this specification, the window manager MAY set the value of the XSync +counter at any time, and MUST do so when it first manages a new +window. -- cgit v1.2.3-54-g00ecf From 09c2ea93eed57a05c49d3812a1d37c0cb096a1f7 Mon Sep 17 00:00:00 2001 From: sandmann Date: Sun, 11 Jul 2004 12:29:04 +0000 Subject: Fix typo --- wm-spec/wm-spec.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/wm-spec/wm-spec.xml b/wm-spec/wm-spec.xml index 929dc17..41cb003 100644 --- a/wm-spec/wm-spec.xml +++ b/wm-spec/wm-spec.xml @@ -1455,7 +1455,7 @@ counter is not defined by this specification. A window manager uses this protocol by preceding a ConfigureNotify event sent to a client by a client message as follows: - + Date: Thu, 16 Dec 2004 13:01:51 +0000 Subject: Fixing the formatting from Waldo Bastian. --- wm-spec/wm-spec.xml | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/wm-spec/wm-spec.xml b/wm-spec/wm-spec.xml index 41cb003..0cc1e3a 100644 --- a/wm-spec/wm-spec.xml +++ b/wm-spec/wm-spec.xml @@ -806,7 +806,7 @@ setting the window's _NET_FRAME_EXTENTS property accordingly. The Client MUST handle the resulting _NET_FRAME_EXTENTS PropertyNotify event. So that the Window Manager has a good basis for estimation, the Client MUST set any window properties it intends to set -before sending this message. The Client MUST be able to cope +before sending this message. The Client MUST be able to cope with imperfect estimates. @@ -1438,6 +1438,8 @@ respond to this protocol within a reasonable time. See also the implementation notes on killing hung processes. + + _NET_WM_SYNC_REQUEST This protocol uses the XSync extension (see - - + After receiving one or more such message/ConfigureNotify pairs, and having handled all repainting associated with the ConfigureNotify -- cgit v1.2.3-54-g00ecf From 76f255cc55a62f7f22cb140124464f2d3a1a48db Mon Sep 17 00:00:00 2001 From: newren Date: Tue, 25 Jan 2005 16:55:05 +0000 Subject: Let clients set _NET_WM_USER_TIME for initial window(s) too (http://mail.gnome.org/archives/wm-spec-list/2005-January/msg00001.html) --- wm-spec/wm-spec.xml | 26 +++++++++++++++----------- 1 file changed, 15 insertions(+), 11 deletions(-) diff --git a/wm-spec/wm-spec.xml b/wm-spec/wm-spec.xml index 0cc1e3a..75052f9 100644 --- a/wm-spec/wm-spec.xml +++ b/wm-spec/wm-spec.xml @@ -1360,17 +1360,21 @@ This property contains the XServer time at which last user activity in this window took place. -Clients should keep the last timestamp from user interaction. and set -this timestamp in this property on every new toplevel window before mapping it. -A client that only deals with core events, might, for example, use the -timestamp of the last KeyPress or ButtonPress event. ButtonRelease and KeyRelease -events should not generally be considered to be user interaction, because an application -may receive KeyRelease events from global keybindings, and generally release events -may have later timestamp than actions that were triggered by the matching press events. -Clients should start setting the property -only after receiving the first event from user interaction, they shouldn't set -it before receiving first input event. The special value of zero on a newly -mapped window means that the window shouldn't initially get focus after being mapped. +Clients should set this property on every new toplevel window, before mapping +the window, to the timestamp of the user interaction that caused the window to +appear. A client that only deals with core events, might, for example, use the +timestamp of the last KeyPress or ButtonPress event. ButtonRelease and +KeyRelease events should not generally be considered to be user interaction, +because an application may receive KeyRelease events from global keybindings, +and generally release events may have later timestamp than actions that were +triggered by the matching press events. Clients can obtain the timestamp that +caused its first window to appear from the DESKTOP_STARTUP_ID environment +variable, if the app was launched with startup notification. If the client does +not know the timestamp of the user interaction that caused the first window to +appear (e.g. because it was not launched with startup notification), then it +should not set the property for that window. The special value of zero on a +newly mapped window can be used to request that the window not be initially +focused when it is mapped. If the client has the active window, it should also update this property -- cgit v1.2.3-54-g00ecf From 2469e29f80358300a823b5c2dadc7c233d7dfcde Mon Sep 17 00:00:00 2001 From: newren Date: Mon, 28 Feb 2005 19:07:46 +0000 Subject: Add a timestamp field to _NET_CURRENT_DESKTOP messages --- wm-spec/wm-spec.xml | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/wm-spec/wm-spec.xml b/wm-spec/wm-spec.xml index 75052f9..9887ea1 100644 --- a/wm-spec/wm-spec.xml +++ b/wm-spec/wm-spec.xml @@ -395,8 +395,13 @@ _NET_CURRENT_DESKTOP message_type = _NET_CURRENT_DESKTOP format = 32 data.l[0] = new_index + data.l[1] = timestamp other data.l[] elements = 0 ]]> + +Note that the timestamp may be 0 for clients using an older version of +this spec, in which case the timestamp field should be ignored. + _NET_DESKTOP_NAMES Date: Wed, 13 Apr 2005 09:09:26 +0000 Subject: A patch from Alexander Strasser to explicitly specify the wm should restore geometry after going back from fullscreen. --- wm-spec/wm-spec.xml | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/wm-spec/wm-spec.xml b/wm-spec/wm-spec.xml index 9887ea1..8aa1cff 100644 --- a/wm-spec/wm-spec.xml +++ b/wm-spec/wm-spec.xml @@ -1083,8 +1083,10 @@ state. _NET_WM_STATE_FULLSCREEN indicates that the window should fill the entire - screen and have no window decorations. For example, a presentation - program would use this hint. + screen and have no window decorations. Additionally the Window + Manager is responsible for restoring the original geometry after a + switch from fullscreen back to normal window. For example, a + presentation program would use this hint. _NET_WM_STATE_ABOVE indicates that the window should be on top of most @@ -2022,6 +2024,10 @@ _NET_WM_PING message now has the client window identified in data.l[2] field. Added _NET_WM_USER_TIME to detect user activity in windows. + +Explicitly specify that the window manager should restore original geometry +when _NET_WM_STATE_FULLSCREEN is reset. + -- cgit v1.2.3-54-g00ecf From ac1b78a2776d6a383942efe8d6bbc5fcf8d41327 Mon Sep 17 00:00:00 2001 From: llunak Date: Wed, 13 Apr 2005 09:14:58 +0000 Subject: Patch by Olivier Chapuis to add source indication to more messages. --- wm-spec/wm-spec.xml | 43 ++++++++++++++++++++++++++++++++++--------- 1 file changed, 34 insertions(+), 9 deletions(-) diff --git a/wm-spec/wm-spec.xml b/wm-spec/wm-spec.xml index 8aa1cff..bb9b5b0 100644 --- a/wm-spec/wm-spec.xml +++ b/wm-spec/wm-spec.xml @@ -665,10 +665,12 @@ _NET_CLOSE_WINDOW message_type = _NET_CLOSE_WINDOW format = 32 data.l[0] = timestamp + data.l[1] = source indication other data.l[] elements = 0 ]]> The Window Manager MUST then attempt to close the window specified. +See for details on the source indication. Rationale: A Window Manager might be more clever than the usual method (send WM_DELETE message if the protocol is selected, XKillClient otherwise). It might introduce a timeout, for example. Instead of duplicating the code, the Window Manager can easily do the job. @@ -693,7 +695,10 @@ _NET_MOVERESIZE_WINDOW (6), SouthWest (7), South (8), SouthEast (9) and Static (10). A gravity of 0 indicates that the Window Manager should use the gravity specified in WM_SIZE_HINTS.win_gravity. The bits 8 to 11 indicate the - presence of x, y, width and height. + presence of x, y, width and height. The bits 12 to 15 indicate the + source (see ), so 0001 indicates + the application and 0010 indicates a Pager or a Taskbar. + The remaining bits should be set to zero. Pagers wanting to move or resize a window may send a @@ -722,14 +727,15 @@ _NET_WM_MOVERESIZE data.l[1] = y_root data.l[2] = direction data.l[3] = button - other data.l[] elements = 0 + data.l[4] = source indication ]]> This message allows Clients to initiate window movement or resizing. They can define their own move and size "grips", whilst letting the Window Manager control the actual operation. This means that all moves/resizes can happen in a consistent manner as - defined by the Window Manager. + defined by the Window Manager. See + for details on the source indication. When sending this message in response to a button press event, button @@ -786,7 +792,7 @@ _NET_RESTACK_WINDOW ]]> This request is similar to ConfigureRequest with CWSibling and CWStackMode flags. It should be used only by pagers, - applications can use normal ConfigureRequests. The source indication field should be therefore set to 1, + applications can use normal ConfigureRequests. The source indication field should be therefore set to 2, see for details. @@ -906,9 +912,12 @@ _NET_WM_DESKTOP message_type = _NET_WM_DESKTOP format = 32 data.l[0] = new_desktop + data.l[1] = source indication other data.l[] elements = 0 ]]> + See for details on the source + indication. The Window Manager MUST keep this property updated on all windows. _NET_WM_WINDOW_TYPE @@ -1116,13 +1125,24 @@ the window got the required attention (usually, that it got activated). To change the state of a mapped window, a Client MUST send a _NET_WM_STATE -client message to the root window (window is the respective window, type -_NET_WM_STATE, format 32, l[0]=<the action, as listed below>, -l[1]=<First property to alter>, l[2]=<Second property to alter>). +client message to the root window: + + + This message allows two properties to be changed simultaneously, specifically to allow both horizontal and vertical maximization to be altered together. -l[2] MUST be set to zero if only one property is to be changed. l[0], the -action, MUST be one of: +l[2] MUST be set to zero if only one property is to be changed. +See for details on the source indication. +l[0], the action, MUST be one of: Lubos Lunak Rob Adams Thomas Fitzsimmons + Olivier Chapuis Søren Sandmann @@ -1977,6 +1998,10 @@ OR OTHER DEALINGS IN THE SOFTWARE. Changes since 1.2 + +Added source indication to _NET_CLOSE_WINDOW, _NET_WM_MOVERESIZE, +_NET_MOVERESIZE_WINDOW, _NET_WM_DESKTOP and _NET_WM_STATE message. + Added _NET_WM_SYNC_REQUEST to allow synchronized repaint of application window and window manager frame during opaque resize. -- cgit v1.2.3-54-g00ecf From 2eafacb23421d25147533a66a9eb8f0f4650a5e4 Mon Sep 17 00:00:00 2001 From: llunak Date: Fri, 13 May 2005 09:49:44 +0000 Subject: 1.3 is final. --- wm-spec/wm-spec.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/wm-spec/wm-spec.xml b/wm-spec/wm-spec.xml index bb9b5b0..41410e0 100644 --- a/wm-spec/wm-spec.xml +++ b/wm-spec/wm-spec.xml @@ -1,7 +1,7 @@ - + + ]>
-- cgit v1.2.3-54-g00ecf From 4012f30c24c5be4a43533d475eb1f2cb6dc34bad Mon Sep 17 00:00:00 2001 From: llunak Date: Fri, 13 May 2005 09:56:22 +0000 Subject: And going for draft 1.4. --- wm-spec/wm-spec.xml | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/wm-spec/wm-spec.xml b/wm-spec/wm-spec.xml index 41410e0..aec71e4 100644 --- a/wm-spec/wm-spec.xml +++ b/wm-spec/wm-spec.xml @@ -1,6 +1,6 @@ + ]>
@@ -1995,6 +1995,11 @@ OR OTHER DEALINGS IN THE SOFTWARE. Change history + + Changes since 1.3 + + + Changes since 1.2 -- cgit v1.2.3-54-g00ecf From 73e37dce84d9c8f41dc55f86a573f07eca066745 Mon Sep 17 00:00:00 2001 From: llunak Date: Fri, 13 May 2005 10:02:17 +0000 Subject: Apparently empty is not liked. --- wm-spec/wm-spec.xml | 2 -- 1 file changed, 2 deletions(-) diff --git a/wm-spec/wm-spec.xml b/wm-spec/wm-spec.xml index aec71e4..14ab1ec 100644 --- a/wm-spec/wm-spec.xml +++ b/wm-spec/wm-spec.xml @@ -1997,8 +1997,6 @@ OR OTHER DEALINGS IN THE SOFTWARE. Change history Changes since 1.3 - - Changes since 1.2 -- cgit v1.2.3-54-g00ecf From 03b66aada502d608ad11b70b810343b89b13ad1d Mon Sep 17 00:00:00 2001 From: llunak Date: Fri, 13 May 2005 10:10:09 +0000 Subject: Validate. --- wm-spec/wm-spec.xml | 3 --- 1 file changed, 3 deletions(-) diff --git a/wm-spec/wm-spec.xml b/wm-spec/wm-spec.xml index 14ab1ec..aadce16 100644 --- a/wm-spec/wm-spec.xml +++ b/wm-spec/wm-spec.xml @@ -1995,9 +1995,6 @@ OR OTHER DEALINGS IN THE SOFTWARE. Change history - - Changes since 1.3 - Changes since 1.2 -- cgit v1.2.3-54-g00ecf From 2eaa7c421ede16abec1da303e9e77a83963fc17a Mon Sep 17 00:00:00 2001 From: llunak Date: Mon, 27 Jun 2005 08:47:55 +0000 Subject: _NET_WM_ACTION_CLOSE indicates _NET_CLOSE_WINDOW may be sent. --- wm-spec/wm-spec.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/wm-spec/wm-spec.xml b/wm-spec/wm-spec.xml index aadce16..48de11e 100644 --- a/wm-spec/wm-spec.xml +++ b/wm-spec/wm-spec.xml @@ -1235,7 +1235,7 @@ _NET_WM_ACTION_FULLSCREEN indicates that the window may be brought to _NET_WM_ACTION_CHANGE_DESKTOP indicates that the window may be moved between desktops. -_NET_WM_ACTION_CLOSE indicates that the window may be closed (i.e. a WM_DELETE_WINDOW +_NET_WM_ACTION_CLOSE indicates that the window may be closed (i.e. a _NET_CLOSE_WINDOW message may be sent). -- cgit v1.2.3-54-g00ecf From f135242f825d609b6717611638d0fa8e8e85ca3d Mon Sep 17 00:00:00 2001 From: llunak Date: Wed, 4 Jan 2006 21:25:33 +0000 Subject: Add _NET_WM_MOVERESIZE_CANCEL . --- wm-spec/wm-spec.xml | 21 ++++++++++++++++++--- 1 file changed, 18 insertions(+), 3 deletions(-) diff --git a/wm-spec/wm-spec.xml b/wm-spec/wm-spec.xml index 48de11e..3d39cae 100644 --- a/wm-spec/wm-spec.xml +++ b/wm-spec/wm-spec.xml @@ -759,9 +759,11 @@ _NET_WM_MOVERESIZE #define _NET_WM_MOVERESIZE_MOVE 8 /* movement only */ #define _NET_WM_MOVERESIZE_SIZE_KEYBOARD 9 /* size via keyboard */ #define _NET_WM_MOVERESIZE_MOVE_KEYBOARD 10 /* move via keyboard */ +#define _NET_WM_MOVERESIZE_CANCEL 11 /* cancel operation */ ]]> - The Client MUST release all grabs prior to sending such message. + The Client MUST release all grabs prior to sending such message (except + for the _NET_WM_MOVERESIZE_CANCEL message). The Window Manager can use the button field to determine the @@ -769,8 +771,13 @@ _NET_WM_MOVERESIZE _NET_WM_MOVERESIZE message. Since there is a race condition between a client sending the _NET_WM_MOVERESIZE message and the user releasing the button, Window Managers are advised to offer some other means to - terminate the operation, e.g. by pressing the ESC key. - + terminate the operation, e.g. by pressing the ESC key. The special value + _NET_WM_MOVERESIZE_CANCEL also allows clients to cancel the operation + by sending such message if they detect the release themselves + (clients should send it if they get the button release after sending + the move resize message, indicating that the WM did not get a grab in time + to get the release). + _NET_RESTACK_WINDOW Change history + + Changes since 1.3 + + +Added _NET_WM_MOVERESIZE_CANCEL. + + + Changes since 1.2 -- cgit v1.2.3-54-g00ecf From f844a8bad3e5e27e7ac72420f934d51c787a2492 Mon Sep 17 00:00:00 2001 From: sandmann Date: Thu, 13 Apr 2006 18:53:08 +0000 Subject: New window types to be used on override-redirect windows: _NET_WM_WINDOW_TYPE_DROPDOWN_MENU, _NET_WM_WINDOW_TYPE_POPUP_MENU, _NET_WM_WINDOW_TYPE_TOOLTIP, _NET_WM_WINDOW_TYPE_NOTIFICATION, _NET_WM_WINDOW_TYPE_COMBO, and _NET_WM_WINDOW_TYPE_DND New _NET_WM_CM_Sn manager selection for compositing managers. Added note WM_TRANSIENT_FOR for override-redirect windows --- wm-spec/wm-spec.xml | 181 ++++++++++++++++++++++++++++++++++++++++++++-------- 1 file changed, 154 insertions(+), 27 deletions(-) diff --git a/wm-spec/wm-spec.xml b/wm-spec/wm-spec.xml index 3d39cae..4d5e869 100644 --- a/wm-spec/wm-spec.xml +++ b/wm-spec/wm-spec.xml @@ -29,16 +29,16 @@ versions. What is this spec? -This spec defines interactions between window managers, applications, -and the utilities that form part of a desktop environment. It builds -on the Inter-Client Communication Conventions Manual ICCCM, which defines -window manager interactions at a lower level. The ICCCM does not provide ways -to implement many features that modern desktop users expect. The GNOME and KDE -desktop projects originally developed their own extensions to the ICCCM to -support these features; this spec replaces those custom extensions -with a standardized set of ICCCM additions that any desktop -environment can adopt. +This spec defines interactions between window managers, compositing +managers, applications, and the utilities that form part of a desktop +environment. It builds on the Inter-Client Communication Conventions +Manual ICCCM, which +defines window manager interactions at a lower level. The ICCCM does +not provide ways to implement many features that modern desktop users +expect. The GNOME and KDE desktop projects originally developed their +own extensions to the ICCCM to support these features; this spec +replaces those custom extensions with a standardized set of ICCCM +additions that any desktop environment can adopt. @@ -221,6 +221,20 @@ documents. These subwindows are decorated with window manager frames and can be manipulated within their parent window just like ordinary top-level windows on the root window. + + Override-redirect windows + +Override-redirect windows are ignored by traditional window managers, +but not by compositing managers. Compositing managers are responsible +for painting all windows to the screen, including override-redirect +windows. + + +To enable compositing managers to decorate override-redirect window +properly, for example by making them translucent or by changing the +shape of the windows, this spec allows clients to set properties on +override-redirect windows indicating the function of the windows. + Layered stacking order @@ -240,9 +254,11 @@ layer. Allow clients to influence their initial state with respect to maximization, shading, stickiness, desktop, stacking order. -Improve the window managers ability to vary window +Improve the window manager's ability to vary window decorations and maintain the stacking order by allowing clients to hint the window manager about the type of their windows. +Improve the compositing manager's ability to apply +decorations and effects to override-redirect windows Enable pagers and taskbars to be implemented as separate clients and allow them to work with any compliant window manager. @@ -941,6 +957,11 @@ window type atoms from the list below. This is to allow for extension of the list of types whilst providing default behavior for Window Managers that do not recognize the extensions. + +This hint SHOULD also be set for override-redirect windows to allow +compositing managers to apply consistent decorations to menus, +tooltips etc. + Rationale: This hint is intended to replace the MOTIF hints. One of the objections to the MOTIF hints is that they are a purely visual description of @@ -958,6 +979,12 @@ _NET_WM_WINDOW_TYPE_MENU, ATOM _NET_WM_WINDOW_TYPE_UTILITY, ATOM _NET_WM_WINDOW_TYPE_SPLASH, ATOM _NET_WM_WINDOW_TYPE_DIALOG, ATOM +_NET_WM_WINDOW_TYPE_DROPDOWN_MENU, ATOM +_NET_WM_WINDOW_TYPE_POPUP_MENU, ATOM +_NET_WM_WINDOW_TYPE_TOOLTIP, ATOM +_NET_WM_WINDOW_TYPE_NOTIFICATION, ATOM +_NET_WM_WINDOW_TYPE_COMBO, ATOM +_NET_WM_WINDOW_TYPE_DND, ATOM _NET_WM_WINDOW_TYPE_NORMAL, ATOM ]]> @@ -971,10 +998,14 @@ _NET_WM_WINDOW_TYPE_DOCK indicates a dock or panel feature. Typically a Window Manager would keep such windows on top of all other windows. -_NET_WM_WINDOW_TYPE_TOOLBAR and _NET_WM_WINDOW_TYPE_MENU indicate toolbar and -pinnable menu windows, respectively (i.e. toolbars and menus "torn off" from -the main application). Windows of this type may set the WM_TRANSIENT_FOR -hint indicating the main application window. +_NET_WM_WINDOW_TYPE_TOOLBAR and _NET_WM_WINDOW_TYPE_MENU indicate +toolbar and pinnable menu windows, respectively (i.e. toolbars and +menus "torn off" from the main application). Windows of this type may +set the WM_TRANSIENT_FOR hint indicating the main application +window. Note that the _NET_WM_WINDOW_TYPE_MENU should be set on +torn-off managed windows, where _NET_WM_WINDOW_TYPE_DROPDOWN_MENU and +_NET_WM_WINDOW_TYPE_POPUP_MENU are typically used on override-redirect +windows. _NET_WM_WINDOW_TYPE_UTILITY indicates a small persistent utility window, such as @@ -990,19 +1021,63 @@ displayed as an application is starting up. _NET_WM_WINDOW_TYPE_DIALOG indicates that this is a dialog window. If -_NET_WM_WINDOW_TYPE is not set, then windows with WM_TRANSIENT_FOR set MUST -be taken as this type. +_NET_WM_WINDOW_TYPE is not set, then managed windows with +WM_TRANSIENT_FOR set MUST be taken as this type. Override-redirect +windows with WM_TRANSIENT_FOR, but without _NET_WM_WINDOW_TYPE must be +taken as _NET_WM_WINDOW_TYPE_NORMAL. - -_NET_WM_WINDOW_TYPE_NORMAL indicates that this is a normal, top-level window. -Windows with neither _NET_WM_WINDOW_TYPE nor WM_TRANSIENT_FOR set MUST -be taken as this type. - - - - _NET_WM_STATE - +_NET_WM_WINDOW_TYPE_DROPDOWN_MENU indicates that the +window in question is a dropdown menu, ie., the kind of menu that +typically appears when the user clicks on a menubar, as opposed to a +popup menu which typically appears when the user right-clicks on an +object. This property is typically used on override-redirect windows. + + +_NET_WM_WINDOW_TYPE_POPUP_MENU indicates that the +window in question is a popup menu, ie., the kind of menu that +typically appears when the user right clicks on an object, as opposed +to a dropdown menu which typically appears when the user clicks on a +menubar. This property is typically used on override-redirect windows. + + +_NET_WM_WINDOW_TYPE_TOOLTIP indicates that the window +in question is a tooltip, ie., a short piece of explanatory text that +typically appear after the mouse cursor hovers over an object for a +while. This property is typically used on override-redirect windows. + + +_NET_WM_WINDOW_TYPE_NOTIFICATION indicates a +notification. An example of a notification would be a bubble appearing +with informative text such as "Your laptop is running out of power" +etc. This property is typically used on override-redirect windows. + + +_NET_WM_WINDOW_TYPE_COMBO should be used on the windows that are +popped up by combo boxes. An example is a window that appears below a +text field with a list of suggested completions. This property is +typically used on override-redirect windows. + + +_NET_WM_WINDOW_TYPE_DND indicates that the window is being +dragged. Clients should set this hint when the window in question +contains a representation of an object being dragged from one place to +another. An example would be a window containing an icon that is being +dragged from one file manager window to another. This property is +typically used on override-redirect windows. + + +_NET_WM_WINDOW_TYPE_NORMAL indicates that this is a normal, top-level +window, either managed or override-redirect. Managed windows with +neither _NET_WM_WINDOW_TYPE nor WM_TRANSIENT_FOR set MUST be taken as +this type. Override-redirect windows without _NET_WM_WINDOW_TYPE, must +be taken as this type, whether or not they have WM_TRANSIENT_FOR set. + + + + _NET_WM_STATE + A list of hints describing the window state. Atoms present in the list MUST be @@ -1532,6 +1607,46 @@ window. + + + Compositing Managers + +A compositing manager is an X client that uses the Composite extension +to redirect all windows to offscreen pixmaps, and the Damage extension +to track when painting occur on those offscreen pixmaps. It is the +responsibility of the compositing manager to paint the pixmaps on the +screen, possibly adding effects like translucency or deformations. + + +This section specifies interactions between compositing managers +and applications. + + + _NET_WM_CM_S<literal>n</literal> Manager Selection + +For each screen they manage, compositing manager MUST acquire +ownership of a selection named _NET_WM_CM_Sn, where +n is the screen number. Compositing managers MUST +comply with the conventions for "Manager Selections" described in +section 2.8 of the ICCCM. + + + + WM_TRANSIENT_FOR for override-redirect windows + +The WM_TRANSIENT_FOR property is defined by the ICCCM.for managed windows. This +specification extends the use of the property to override-redirect +windows. If an override-redirect is a pop-up on behalf of another +window, then the Client SHOULD set WM_TRANSIENT_FOR on the +override-redirect to this other window. + + +As an example, a Client should set WM_TRANSIENT_FOR on dropdown menus +to the toplevel application window that contains the menubar. + + + Implementation notes @@ -2008,6 +2123,18 @@ OR OTHER DEALINGS IN THE SOFTWARE. Added _NET_WM_MOVERESIZE_CANCEL. + +New window types to be used on override-redirect windows: +_NET_WM_WINDOW_TYPE_DROPDOWN_MENU, _NET_WM_WINDOW_TYPE_POPUP_MENU, +_NET_WM_WINDOW_TYPE_TOOLTIP, _NET_WM_WINDOW_TYPE_NOTIFICATION, +_NET_WM_WINDOW_TYPE_COMBO, and _NET_WM_WINDOW_TYPE_DND + + +New _NET_WM_CM_Sn manager selection for compositing managers. + + +Added note WM_TRANSIENT_FOR for override-redirect windows + -- cgit v1.2.3-54-g00ecf From 1a243dc66f738cc8a95879bc4c14d6a8206c4893 Mon Sep 17 00:00:00 2001 From: llunak Date: Mon, 29 May 2006 11:40:53 +0000 Subject: Close . --- wm-spec/wm-spec.xml | 1 + 1 file changed, 1 insertion(+) diff --git a/wm-spec/wm-spec.xml b/wm-spec/wm-spec.xml index 4d5e869..7eb92b1 100644 --- a/wm-spec/wm-spec.xml +++ b/wm-spec/wm-spec.xml @@ -234,6 +234,7 @@ To enable compositing managers to decorate override-redirect window properly, for example by making them translucent or by changing the shape of the windows, this spec allows clients to set properties on override-redirect windows indicating the function of the windows. + Layered stacking order -- cgit v1.2.3-54-g00ecf From f0f4972d935f749a25361798ac22843bf8024477 Mon Sep 17 00:00:00 2001 From: mclasen Date: Fri, 29 Sep 2006 13:54:53 +0000 Subject: Add _NET_WM_USER_TIME_WINDOW --- wm-spec/wm-spec.xml | 33 +++++++++++++++++++++++++++++---- 1 file changed, 29 insertions(+), 4 deletions(-) diff --git a/wm-spec/wm-spec.xml b/wm-spec/wm-spec.xml index 7eb92b1..a8d3671 100644 --- a/wm-spec/wm-spec.xml +++ b/wm-spec/wm-spec.xml @@ -1,7 +1,7 @@ - + + ]>
@@ -1470,7 +1470,8 @@ This property contains the XServer time at which last user activity in this window took place. -Clients should set this property on every new toplevel window, before mapping +Clients should set this property on every new toplevel window (or on the window +pointed out by the _NET_WM_USER_TIME_WINDOW property), before mapping the window, to the timestamp of the user interaction that caused the window to appear. A client that only deals with core events, might, for example, use the timestamp of the last KeyPress or ButtonPress event. ButtonRelease and @@ -1498,8 +1499,29 @@ action or is a "pop-up" window activated by a timer or some other event. + + _NET_WM_USER_TIME_WINDOW + + +This property contains the XID of a window on which the client sets +the _NET_WM_USER_TIME property. Clients should check whether the +window manager supports _NET_WM_USER_TIME_WINDOW and fall back to +setting the _NET_WM_USER_TIME property on the toplevel window if it +doesn't. + + +Rationale: Storing the frequently changing _NET_WM_USER_TIME property +on the toplevel window itself causes every application that is +interested in any of the properties of that window to be woken up +on every keypress, which is particularly bad for laptops running on +battery power. + + + _NET_FRAME_EXTENTS - @@ -2136,6 +2158,9 @@ New _NET_WM_CM_Sn manager selection for compositing managers. Added note WM_TRANSIENT_FOR for override-redirect windows + +Added _NET_WM_USER_TIME_WINDOW. + -- cgit v1.2.3-54-g00ecf From 88805125c4bb6fecc149793366bd011887f8dd73 Mon Sep 17 00:00:00 2001 From: llunak Date: Fri, 13 Oct 2006 16:03:28 +0000 Subject: Add _NET_WM_FULL_PLACEMENT (http://mail.gnome.org/archives/wm-spec-list/2006-August/msg00000.html). --- wm-spec/wm-spec.xml | 37 +++++++++++++++++++++++++++++++++++++ 1 file changed, 37 insertions(+) diff --git a/wm-spec/wm-spec.xml b/wm-spec/wm-spec.xml index a8d3671..68ca3df 100644 --- a/wm-spec/wm-spec.xml +++ b/wm-spec/wm-spec.xml @@ -1631,6 +1631,40 @@ window. + + + Other Properties + + _NET_WM_FULL_PLACEMENT + +By including this hint in _NET_WM_SUPPORTED_LIST the Window Manager announces +that it performs reasonable window placement for all window types it supports +(for example centering dialogs on the mainwindow or whatever handling the +Window Manager considers reasonable). This in turn means that Clients, +when they detect that this hint is supported, SHOULD NOT abuse or often even +use PPosition and USPosition hints for requesting placement. In particular: + + +USPosition is reserved to be used only to indicate that the position was +specified by the user and MUST NOT be used for anything else (see ICCCM +section 4.1.2.3 for details) +PPosition SHOULD be used for for specifying position only if a specific +position should be used. Position SHOULD NOT be specified for "default" +placement such as centering dialog windows on their mainwindow. + + +Rationale: Window managers can often perform better placement (that may be +even configurable) for windows than the application. However at the time of +writing this it is problematic for Window managers to decide when to use them +because many applications abuse positioning flags and/or provide unnecessary +default positions. + + +Note: The property is not used anywhere else besides being listed in _NET_WM_SUPPORTED_LIST. + + + + Compositing Managers @@ -2161,6 +2195,9 @@ Added note WM_TRANSIENT_FOR for override-redirect windows Added _NET_WM_USER_TIME_WINDOW. + +Added _NET_WM_FULL_PLACEMENT. + -- cgit v1.2.3-54-g00ecf From ff9e6f295c03d978f848fbe9e04adfe0402cde97 Mon Sep 17 00:00:00 2001 From: newren Date: Thu, 12 Apr 2007 23:18:54 +0000 Subject: Add _NET_WM_ACTION_ABOVE and _NET_WM_ACTION_BELOW --- wm-spec/wm-spec.xml | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/wm-spec/wm-spec.xml b/wm-spec/wm-spec.xml index 68ca3df..97ef62b 100644 --- a/wm-spec/wm-spec.xml +++ b/wm-spec/wm-spec.xml @@ -1265,6 +1265,8 @@ _NET_WM_ACTION_MAXIMIZE_VERT, ATOM _NET_WM_ACTION_FULLSCREEN, ATOM _NET_WM_ACTION_CHANGE_DESKTOP, ATOM _NET_WM_ACTION_CLOSE, ATOM +_NET_WM_ACTION_ABOVE, ATOM +_NET_WM_ACTION_BELOW, ATOM ]]> An implementation MAY add new atoms to this list. Implementations @@ -1321,6 +1323,12 @@ _NET_WM_ACTION_CHANGE_DESKTOP indicates that the window may be moved between des _NET_WM_ACTION_CLOSE indicates that the window may be closed (i.e. a _NET_CLOSE_WINDOW message may be sent). + +_NET_WM_ACTION_ABOVE indicates that the window may placed in the "above" layer of windows (i.e. will respond to _NET_WM_STATE_ABOVE changes; see also for details). + + +_NET_WM_ACTION_BELOW indicates that the window may placed in the "below" layer of windows (i.e. will respond to _NET_WM_STATE_BELOW changes; see also for details)). + _NET_WM_STRUT -- cgit v1.2.3-54-g00ecf From a95af55a102b0814e81095bda46a691068009c3c Mon Sep 17 00:00:00 2001 From: llunak Date: Mon, 17 Mar 2008 14:48:05 +0000 Subject: Added _NET_WM_FULLSCREEN_MONITORS. --- wm-spec/wm-spec.xml | 61 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 61 insertions(+) diff --git a/wm-spec/wm-spec.xml b/wm-spec/wm-spec.xml index 97ef62b..98f9f9b 100644 --- a/wm-spec/wm-spec.xml +++ b/wm-spec/wm-spec.xml @@ -1637,6 +1637,63 @@ counter at any time, and MUST do so when it first manages a new window. + + _NET_WM_FULLSCREEN_MONITORS + + +A read-only list of 4 monitor indices indicating the top, bottom, left, and +right edges of the window when the fullscreen state is enabled. The indices +are from the set returned by the Xinerama extension. + + +Windows transient for the window with _NET_WM_FULLSCREEN_MONITORS set, such as +those with type _NEW_WM_WINDOW_TYPE_DIALOG, are generally expected to be +positioned (e.g. centered) with respect to only one of the monitors. This +might be the monitor containing the mouse pointer or the monitor containing the +non-full-screen window. + + +A Client wishing to change this list MUST send a _NET_WM_FULLSCREEN_MONITORS +client message to the root window. The Window Manager MUST +keep this list updated to reflect the current state of the window. + + + +See for details on the source indication. + + +Virtual machine software may use this hint to have a virtual operating system +instance that sees multiple monitors. The application window stretches over +several monitors, giving the appearance that these monitors have been taken +over by the guest virtual machine. + + +This hint might also be used by a movie or presentation application allowing +users to display the media spanned over several monitors. + + +In both cases, the application would have some user interface allowing users +to configure which monitors the application fullscreens to. The window manager +need not provide such an interface, though it could. + + +In the event of a change in monitor configuration, the application is +responsible for re-computing the monitors on which it wants to appear. +The window manager may continue using the same monitor indices as before +or simply clear the list, returning to "normal" fullscreen. + + @@ -2179,6 +2236,7 @@ OR OTHER DEALINGS IN THE SOFTWARE. Thomas Fitzsimmons Olivier Chapuis Søren Sandmann + Grant Patterson Change history @@ -2206,6 +2264,9 @@ Added _NET_WM_USER_TIME_WINDOW. Added _NET_WM_FULL_PLACEMENT. + +Added _NET_WM_FULLSCREEN_MONITORS. + -- cgit v1.2.3-54-g00ecf