Draft 1.9b - some comments

[Matthias Ettrich <ettrich troll no>]

Hi, 

sorry for being silent for such a long time. I finally found the mood to examine
some of the discussion we had previously and to checkout the Draft 1.9b.

It's quite well done, thanks Marko and the other contributors.

I still see some points, though:

1) Is it *really* common opinion that we shouldn't introduce an extensible,
future-safe  _NET_WM_DECORATION hint but rather stick with the Motif MWM hints?
In that case: How am I supposed to decorate MS-like tool-windows (titlebar and
buttons like a real window, only smaller. In fact, even smaller than transient
windows)?

Dropping MWM hints has another advantage: one roundtrip less since
_NET_WM_DECORATION will of course be integrated with the other properties.

I recall some discussion about that, can somebody please summarize the state
regarding this?


2) window caption / icon name and unicode

We discussed that briefly, but didn't find a conclusion yet AFAIK. Jim
suggested to *define* the caption and the icon name (and some others) as being
UTF8. The solution is a) elegant, b) easy to implement and c) won't break
US-ascii-applications and window managers.  BUT: it will break other settings
where applications and window managers use a local encoding different from
US-ascii. 

Personally I'm scared that we might break too much. Not sure, though.

The most-compatible solution would be to introduce two new properties for both
the window caption and the icon name that are defined as utf8.


3) struts, currently defined as:

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

I promised a more detailed explanation some time ago, here it is:

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 (and applications) should be able to know about this reserved
space in order to be able to preserve the space. Also maximized windows should
not cover that reserved space.

One might think that another hint "DO_NOT_COVER" on the panel window might be
enough, the window manager could perform all other operations. Unfortunately
this is not sufficient.

Let me use the KDE-1.x desktop panel as an example. In the default mode it's
just an omni present ( = sticky) panel, on all desktops. The reserved space
is exactly the geometry of the window. So far it's easy.

But some users like to have an auto-hide feature. The panel then slides out of
the screen, with just one or pixels remaining visible. It is clear that the
reserved space is just these two pixels, the whole purpose of the auto-hide
feature is to get more space for applications. Now consider the following race
condition: you move the mouse over the hidden panel, the panel slides in. Then
you maximize a window _before_ the panel slides back again. What size will that
maximized window get?  

It is tempting to adjust maximized windows dynamically, but do we really want
to resize big applications each time an auto-hide panel slides in  or out? IMO
the panel should rather slide OVER the maximized application, and dissappear
gently afterwards.

This is where the strut concept comes in. The four strut values define the
space at the desktop edges that a window wants to reserve. This space is totally
independent from the window's current geometry.

Last not least kpanel had the nifty feature to be visible on some desktops but
hidden on others. This is why I extended WM_STRUT to allow different struts on
different desktops.

The property isn't complete, though. What's still lacking is a read-only
property on the root window, created by the window manager, that propagates the
maximum rectangle that can be used by applications ( i.e. the geometry a
maximized window on a certain desktop would get ).

What about _NET_WM_MAX_WINDOW_RECT for this purpose?



Matthias