Re: Fwd: Draft 1

[Matthias Ettrich <ettrich troll no>]

On Sun, 20 Jun 1999, Matthias Clasen wrote:
> > 
> > _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.

They do? Why?

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

A wm changes the location of a window every time the user selects an item
in the sendToDesktop submenu of the window menu.

A client changes the location for example when started with a "-desktop <...>"
command line switch ( at least the initial location). There's no point in
forbidding clients to change the location runtime as well.

You seem to have a problem that properties are mixed with client messages. I
don't really understand this, since the responsibility is well defined.
Whenever a window is withdrawn, the client is allowed to change the property,
otherwise it's the WM's tasks. This is very similar to standard ICCCM
behaviour. The unmap notify, just to mention an example, is also done with
additional client messages to the root window in case the window is already
unmapped ( to indicate that the WM shall withdraw it).


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

NO NO NO, this is a common missunderstanding and many wms get it wrong.
WM_TRANSIENT is a hint meant for normal dialogs. It may be slightly less
decorated (for example there's no need for an iconify or maximize button) but
it should have all handles required to move/resize it.

DECORATION_TOOL is something like the small tools with titlebar known from for
example CorelDraw. TINY is almost like DECORATION_NONE but has a small frame
around it (no titlebar) so the window can be resized/move with the window
manager.

If we have all this, there's absolutely no need to do without DECORATION_NONE,
even if the old MOTIF hints offers a way to achieve this.

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

I dissagree. The others (toolwindow, tiny) are as important. Tiny for example
for floating toolbars. We have the chance to define a clean protocol, we should
take it.

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

The macintosh had it first. It's extremely practical, cause it's easier to hit
than a narrow border.

Applications can emulate the resizing, but they would lose special WM features
like snapToBorder or even basic things like transparent resize if the users
wants that.


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

I'll send a more detailed explanation soon. Basically, struts reserve some
space on the screen. This is useful for things like panels or taskbars.
The concept has some significant advantages over a "do not cover" hint (more
soon).

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

Nope, every WM should have a window menu "SendToDesktop"->"Names of Desktop",
at least kwm has it (and so did dtwm).


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

The manpage to XSetInputFocus says:

       The specified focus window must be viewable at the time
       XSetInputFocus is called, or a BadMatch error results.  

Think of" activating another window" as the action that happens if you click on
the respective taskbar icon. That means: switching to the right virtual desktop
if necessary, mapping and raising the window. But again: we define
functionality, not policy. Every windowmanager may have different ideas what
activating means. It's up to the wm.

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

What's arbitrary about CLOSE_WINDOW?  What alternative do you propose if you
want to make it possible for taskbars to actually close a window without
playing window manager themselves?


Matthias