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-70-g09d2