Re: WIP: wm-spec 1.9b

[Tim Janik <timj gtk org>]

On Sun, 22 Aug 1999, Marko Macek wrote:

> 1. Root Window Properties (+Related Messages)
> ---------------------------------------------
> 
> _NET_SUPPORTED, ATOM[]/32
> 
> This property is supposed to be set by the window manager to indicate
> whether which protocol hints are supported. This assumes that backwards
> incompatible changes will not be made to the hints (without being
> renamed).
> 
> _NET_CLIENT_LIST, XA_WINDOW[]/32
> _NET_CLIENT_LIST_STACKING, XA_WINDOW[]/32
> 
> 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 is simple. Does anyone feel we need a faster mechanism based  on
> incremental updates? (based selection query + ADD/REMOVE updates, we
> must  be careful about race conditions if we do this)?
> It would be nice to have a query for managed windows in Z-order, for
> external implementation of Alt-Tab]]

to reduce traffic, we might want to define a certain property that an
application must set on one of its windows if it wants to rely on
thorough updates of _NET_CLIENT_LIST_STACKING, e.g. _NET_PAGER_PRESENT.


> _NET_NUMBER_OF_DESKTOPS <#desktops>, CARDINAL/32
> 
> The number of virtual desktops. If a client wants to change the number
> of desktops, it can send a _NET_NUMBER_OF_DESKTOPS client message to
> the root window (type _NET_NUMBER_OF_DESKTOPS, format 32, l[0]=<new
> number>) 
> 
> If the clients wants to delete/insert a certain desktop, it must send
> _NET_{INSERT/DELETE}_DESKTOP to the root window (l[0] = desktop to
> insert/delete, (insert must also work for appending one desktop). When
> a desktop is deleted, it's windows get moved to the  newly active
> desktop (=the current desktop if some other desktop was deleted, the
> next desktop if current desktop was deleted, or the last desktop if the
> last desktop was deleted). This operation should not be ordinarily
> performed by normal applications.
> 
> _NET_DESKTOP_GEOMETRY width,height, CARDINAL[2]/32
> 
> Array of two Cardinals that defines the width and height of each
> desktop in pixel. If a client wants to change the desktop geometry, it
> can send a _NET_DESKTOP_GEOMETRY client message to the root window
> (type _NET_DESKTOP_GEOMETRY, format 32, l[0]=<new width>, l[1]=<new
> height>).
> 
> _NET_DESKTOP_VIEWPORT x,y, CARDINAL[2]/32
> 
> Array of two Cardinals that defines the toplevel corner of the current
> view. For window managers that don't support paged desktops, this is
> always (0,0). If a client wants to change the desktop viewport, it can
> send a _NET_DESKTOP_VIEWPORT client message to the root window (type
> _NET_DESKTOP_VIEWPORT, format 32, l[0]=<new x>, l[1]=<new y> ). 


this definitely needs to be an array of two cardinals for all dsktops
present. if a pager is only supplied with information about the viewport
of the current desktop, it cannot provide correct thumbnails of the
non-visible desktops. it'd be sufficient for _NET_DESKTOP_VIEWPORT to
be a readonly property, if we introduce a _NET_DESKTOP_CURRENT_VIEWPORT
client message that the pager can use to change the viewport for the
current desktop (i doubt that there'd be any use for applications to
change the viewport for desktops other than the current):

_NET_DESKTOP_VIEWPORT x,y, CARDINAL[][2]/32
 
Readonly property set by WM upon viewport changes within any of the
desktops it provides. Contains two Cardinals per desktop (x,y) that define
the toplevel corner of their current views (the first (x,y)-pair identifies
the coordinates for desktop 1, the second (x,y)-pair for desktop 2 and so
on). For window managers that don't support paged desktops, this is always
an array of (0,0) pairs.

_NET_DESKTOP_CURRENT_VIEWPORT x,y CARDINAL[2]/32

If a client wants to change the current desktop's viewport, it can send a
_NET_DESKTOP_CURRENT_VIEWPORT client message to the root window (type
_NET_DESKTOP_CURRENT_VIEWPORT, format 32, l[0]=<new x>, l[1]=<new y> ).
The viewport change will be reflected in a _NET_DESKTOP_VIEWPORT update
by the window manager.

> _NET_CURRENT_DESKTOP <desktop>, CARDINAL[1]/32
> 
> The index of the current desktop, starts with desktop 1. If a client
> wants to switch to another virtual desktop, it can 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. Text Property. Can be changed by
> anyone (by pager for example, when renaming desktops).
> 
> [[Should WM update this when modifying desktop count?]]

definitely, i think the window manager should even double check client
changes to this property and ensure that it always contains as many
names as are desktops present.

> [[What does this mean with respect to Unicode if anything?]]
> 
> _NET_ACTIVE_WINDOW, WINDOW/32
> 
> 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 can send a
> _NET_ACTIVE_WINDOW client message request to the root window (window
> is the respective window, type _NET_ACTIVE_WINDOW, format 32,
> l[0]=0 /*may be used later*/ )
> 
>   Rationale: XSetInputFocus is not sufficient, since the window may be
>   hidden on another virtual desktop ( in that case XSetInputFocus
>   fails with a BadWindow error )
> 
> _NET_WORKAREA CARDINAL[][4]/32
> 
> Readonly property set by WM upon calculating the work area for each
> desktop. (the first quadruple = desktop 1, etc).
> Contains the left,right,top,bottom coordinates for each desktop.
> Work area is used for maximizing windows and by the desktop to place
> desktop icons appropriatelly.
> 
> Work area refers to current page minus space occupied by panels, docks
> etc.  The purpose is to ensure that maximised applications do not cover
> panels, and so that desktop icons don't get put under panels. 
> 
> [[IMHO having different work areas on different desktops is messy,
> although flexible]].
> 
> 2. Other Root Window Messages
> -----------------------------
> 
> _NET_CLOSE_WINDOW
> 
> Clients that wish to close another client ( typical examples are
> pagers or taskbars ), shall send a _NET_CLOSE_WINDOW client message
> request to the root window (window is the respective window that shall
> be closed, type _NET_ACTIVE_WINDOW, format 32, l[0]=0 /*may be used
> later*/ )
> 
>   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 close code, the WM can easily do the job.
> 
> _NET_WM_MOVERESIZE
> 
> When application wishes to initiate window resizing it must send
> a message to the root window:
> 
>    window = target app window
>    message_type = _NET_WM_MOVERESIZE
>    format = 32
>    data.s[0] = x_root
>    data.s[1] = y_root
>    data.s[2] = direction:
> 
> #define _NET_WM_MOVERESIZE_DIRECTION_TOPLEFT 0 /* towards the top-left
> */
> #define _NET_WM_MOVERESIZE_DIRECTION_TOP 1 /* towards the top */
> #define _NET_WM_MOVERESIZE_DIRECTION_TOPRRIGHT 2 /* towards the
> top-right */
> #define _NET_WM_MOVERESIZE_DIRECTION_RIGHT 3 /* towards the right */
> #define _NET_WM_MOVERESIZE_DIRECTION_BOTTOMRIGHT 4 /* towards the
> bottom-right*/
> #define _NET_WM_MOVERESIZE_DIRECTION_BOTTOM 5 /* towards the bottom */
> #define _NET_WM_MOVERESIZE_DIRECTION_BOTTOMLEFT 6 /* towards the
> bottom-left */
> #define _NET_WM_MOVERESIZE_DIRECTION_LEFT 7 /* towards the left */
> #define _NET_WM_MOVERESIZE_DIRECTION_MOVE 8 /* only movement */

how is that different from plain usage of XMoveResizeWindow() which
will be caught by the window manager anyways? and what is the direction
meant for if x_root and y_root are specfied anyways?

> 3. Application Window Properties
> --------------------------------
> 
> _NET_PROPERTIES, ATOM[]/32
> 
> Enables only use of listed properties on this window. If this property
> is set, the WM will only handle (XGetWindowProperty) properties listed
> here. This property must be set 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 and MOTIF hints that are set by the
> client. If WM_PROTOCOLS is not listed here, the WM is safe to assume
> that it contains exactly WM_DELETE_WINDOW.
> 
> This is a performance optimization.
> 
> [[I still have to do a benchmark.]]
> 
> _NET_WM_DESKTOP <desktop>, CARDINAL[1]/32
> 
> Cardinal to determine the desktop the window is in (or wants to be),
> starting with 1 for the first desktop. 0 indicates that the window is
> withdrawn and the window manager is free to place it. 0xFFFFFFFF
> indicates
> that window appears on all desktops/workspaces.

how is 0xFFFFFFFF here different from sticky/fixed position?
i think it is messy to intermix an index number with a flag value,
especially since i don't see the point here.

> A window manager honors _NET_WM_DESKTOP whenever a withdrawn window
> requests to be mapped.  When being in another state (iconified or
> mapped), the client can request a change 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>) If <desktop> is set to
> 0, 
> the window is mapped to the current desktop.
> 
> _NET_WM_LAYER, CARDINAL/32
> 
> #define _NET_WIN_LAYER_DESKTOP                0
> #define _NET_WIN_LAYER_BELOW                  2
> #define _NET_WIN_LAYER_NORMAL                 4
> #define _NET_WIN_LAYER_ONTOP                  6
> #define _NET_WIN_LAYER_DOCK                   8
> #define _NET_WIN_LAYER_ABOVE_DOCK             10
> #define _NET_WIN_LAYER_MENU                   12
> 
> The intentions are as follows:
> 
> DESKTOP: A single window at the bottom should be a desktop with icons.
> It should have the same dimensions as the screen.
> [[Even with virtual scrolling desktop?]]
> This allows the desktop environment to have full control of the desktop.
> (With focusing, background handling and no shaped windows).
> 
> NORMAL: the default for all windows
> 
> ONTOP,BELOW: Normal window that stay on top/below other windows.
> 
> DOCK: Windows docked at the edge of the screen.
> 
> MENU: layer for NextStep/WMaker style menus that stay on top.
> 
> [[Some adjustments for DOCK might be necessary when _NET_WM_STRUT is
> finalized]]
> 
> _NET_WM_STATE CARDINAL/32
> 
> #define _NET_WM_STATE_STICKY (1<<0) /* the window sticks on the screen
> even when the virtual desktop scrolls */
> REMOVED: #define _NET_WM_STATE_OMNIPRESENT (1<<1) /* the window is
> visible on all
> virtual desktops */
> #define _NET_WM_STATE_MAXIMIZED_VERT (1<<2)  /* the window is vertically
> maximized */
> #define _NET_WM_STATE_MAXIMIZED_HORZ (1<<3)  /* the window is
> horizontally maximized */
> #define _NET_WM_STATE_SHADED (1<<4)  /* the window is shaded */
> 
> A window manager honors _NET_WM_STATE whenever a withdrawn window
> requests to be mapped.  When being in another state (iconified or
> mapped), the client can request a change by sending a _NET_WM_STATE
> client message to the root window. (window is the respective window,
> type _NET_WM_STATE, format 32, l[0]=<mask>, l[1]=<new values for masked
> bits> )
> 
> [[A big problem with this property is that is not extensible by anyone.
> Someone needs to arbitrate the bits]].
> 
> _NET_WM_HINTS CARDINAL/32
> Additional hints for the window manager or tools like panels or
> taskbars.
> Possible values:
> 
> #define _NET_WM_HINTS_SKIP_FOCUS (1<<0) /* "alt-tab" skips this win */
> #define _NET_WM_HINTS_SKIP_WINLIST (1<<1)  /* do not show in window list
> */
> #define _NET_WM_HINTS_SKIP_TASKBAR (1<<2) /* do not show on taskbar */
> #define _NET_WM_HINTS_NO_AUTO_FOCUS (1<<3) /* do not automatically put
> focus on this window when it pops up */
> #define _NET_WM_HINTS_STANDALONE_MENUBAR  (1<<4) /* this window is a
> standalone menubar */
> #define _NET_WM_HINTS_IGNORE_ARRANGE  (1<<5) /* this window has a fixed
> position (should be excluded from desktop uncluttering etc.) */
> #define _NET_WM_HINTS_DO_NOT_COVER (1<<6) /* attempt to never cover up
> this window if possible (placement policy priority hint)*/
> #define _NET_WM_HINTS_LOCK_ZORDER (1<<7) /* window will not be raised
> when clicked even if WM does this for normal windows)*/
> //remove?: #define _NET_WM_HINTS_NO_MOVE_WITH_OWNER (1<<8) /* for
> transient
> windows, will not be moved when owner is moved/sized */
> 
> A window manager honors _NET_WM_HINTS whenever a withdrawn window
> requests to be mapped.  When being in another state (iconified or
> mapped), the client can request a change by sending a _NET_WM_HINTS
> client message to the root window.  (window is the respective window,
> type _NET_WM_HINTS, format 32, l[0]=<mask>, l[1]=<new values for masked
> bits> )
> 
> [[Also not extensible.]]
> 
> _NET_WM_STRUT CARDINAL[][4]/32
> 
> An array of struts. Strut[0] is the global strut, i.e. it appears on
> all virtual desktops. The optional following struts appear only on
> their respective virtual desktop.  A strut is defined as 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, a window manager therefore has to watch out for property
> notify events. A strut is valid when the window is mapped relatively
> to its virtual desktop.
> 
> Type _NET_WM_CARDINAL, format 32.
> 
> [[Mathiass, please describe this in more detail]]
> 
> _NET_WM_ICON_GEOMETRY
> 
> An array 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_PROPERTIES (recommended) or WM_PROTOCOLS:
> ======================
> 
> _NET_WM_SIZEMOVE_NOTIFY
> 
> If this protocol is selected, the window will receive
> _NET_WM_SIZEMOVE_BEGIN and _NET_WM_SIZEMOVE_END client messages when the
> window manager starts or ends resizing in opaque mode.
> 
>   Rationale: This allows slow applications to use a faster resizing
>   method until they finally receive the _NET_WM_SIZEMOVE_EXIT hint.

so we got _NET_WM_SIZEMOVE_NOTIFY, _NET_WM_SIZEMOVE_BEGIN,
_NET_WM_SIZEMOVE_END and _NET_WM_SIZEMOVE_EXIT client messages?
what about:

_NET_WM_SIZEMOVE_NOTIFY (first sizemove notify, treat as _BEGIN)
_NET_WM_SIZEMOVE_NOTIFY
_NET_WM_SIZEMOVE_NOTIFY
[further notification]
_NET_WM_SIZEMOVE_DONE (next _NET_WM_SIZEMOVE_NOTIFY will be treated as
                       _BEGIN again)


> 
> [[Changed to include resizing only. Do we need move too? In that case
> we need to report what is actually being done]]

windows that embed overlay video will want to update the overlay
area during plain moves as well.


---
ciaoTJ