Re: Fwd: Draft 1

[Matthias Clasen <clasen pong mathematik uni-freiburg de>]

> 
> _NET_WM_LOCATION <desktop>
> 
> 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. Type CARDINAL,
> format 32.
> 

Some wms (eg fvwm) allow negative desk numbers.

> A window manager honors _NET_WM_LOCATION 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_LOCATION
> client message to the root window. (window is the respective window,
> type _NET_WM_LOCATION, format 32, l[0]=<desktop>)
> 

I would prefer to use properties for one-way communication. Either 
let the client set _NET_WM_LOCATION to change its location (btw can
anybody tell me a good reason why a client would want to do so ?) 
Then a client-message is unnecessary, the wm can simply listen for
PropertyChange events.

Or let the wm set _NET_WM_LOCATION to always reflect the actual location
of the client window. In this case clients have to use client-messages
to change their desk. 


> _NET_WM_DECORATION
> 
> How the window's decoration frame should look like. Possible values
> are None, Normal, Tiny, and Tool.
> 
> #define _NET_WM_DECORATION_NONE 0  /* the window should not be decorated at all (but managed!)*/
> #define _NET_WM_DECORATION_NORMAL 1  /* normal decoration */
> #define _NET_WM_DECORATION_TINY 2  /* a tiny decoration, just a small frame that fits into the look and feel */
> #define _NET_WM_DECORATION_TOOL 3 /* a toolwindow, i.e. slightly smaller decorations */

How does this relate to existing standard hints (eg motif decoration hings) ?
I think you can achieve DECORATION_NONE with motif hints (this is how gmc's
desktop icons do it) and have the added bonus that it works with existing wms.
DECORATION_TINY sounds a bit like a duplication of WM_TRANSIENT. 

>   Rationale: especially DEORATION_NONE is very important. It allows
>   application developers to create borderless windows ( for example
>   taskbars, desktop panels or application specific floating toolbars )
>   without the need of making them override_redirect. This way the
>   window can benefit from the window manager's focus handling, which
>   isn't possible at all with override_redirect windows.

If you are mostly interested in DECORATION_NONE, then lets re-use the
existing motif hints rather than introduce new ones.

> _NET_WM_MOVERESIZEGRIP
> 
> Defines an array of childwindows that serves as move or sizegrips. The
> windowmanager may install a passive button grab on these windows to
> takeover the resize or move handling. The property is handled when a
> window becomes mapped the very first time (map request). Type
> XA_WINDOW, format 32.
> 

Interesting idea. I guess this is mostly to imitate the Win95 triangular
resize corners ?

> 
> _NET_WM_STRUT
> 
> 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.

What are struts used for ?
 
> 
> _NET_DESKTOP_NAMES
> The names of all virtual desktops. Text Property.
> 

I don't think a wm should be concerned with desktop names. These are
only interesting to pagers and the like.

> 
> _NET_ACTIVE_WINDOW
> 
> 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 )

What are the exact semantics of activating another window ? As you
noted, simply putting the focus on it may not be possible for the wm.
So should it automatically switch desktop and viewport to make the new
window visible ?

> 
> _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.

This goes in the direction of sending arbitrary wm commands via properties
which may not be the best way to do it. 

-- 
Matthias Clasen, 
Tel. 0761/203-5606
Email: clasen@mathematik.uni-freiburg.de
Mathematisches Institut, Albert-Ludwigs-Universitaet Freiburg