Fwd: Draft 1

[Michael Rogers <m rogers cs ucl ac uk>]

To keep this reasonably short, I've snipped the suggestions I agree
with.

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

Do we need more ways of describing icons? We have traditional X icons
(minimised applications), GMC icons (shortcuts), and now an icon whose
position and size is dictated by the application? That's going to look
very messy.


> _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 */
>
>   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.
>
> Type CARDINAL, format 32.

Does this mean we're abandoning MWM hints? They seem to cover eveything
proposed here (except "tool" decorations).


> _NET_WM_LAYER
>
> #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
>
> Type CARDINAL, format 32

I don't understand the function of the MENU layer. It seems to exist for
the benefit of the root menu, which could just set override_redirect. I
also
don't agree with the original proposal of having intermediate layers -
too many layers will create confusion when the user is trying to restack
windows. How about a much simpler scheme:

#define _NET_WIN_LAYER_DESKTOP   0
#define _NET_WIN_LAYER_BELOW     1
#define _NET_WIN_LAYER_NORMAL    2
#define _NET_WIN_LAYER_ABOVE     3


> #define _NET_WM_HINTS_STANDALONE_MENUBAR  (1<<4) /* this window is a standalone menubar */

What does this imply for the window manager?


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

I have reservations about using two applications (pager and window
manager) to do the same job. A large part of the current spec seems to
exist to help the Gnome pager communicate with window managers, many of
which provide pagers of their own, or alternative methods which work
just as well. Wouldn't it be easier to just abandon the Gnome pager, and
let the window manager manage the windows? Any window managers which
wanted to include a panel applet for switching tasks could do so. I
don't know what the situation is with KDE/XFCE, of course.


Michael Rogers