Re: Fwd: Draft 1

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

> _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.
> 
> The default is resize to bottom right. But the grips may define an
> additional property _NET_WM_MOVERESIZE_DIRECTION of Type XA_CARDINAL,
> Format32 with the following values:
> 

I have thought a little more about this. While it may be a nice feature,
there are some caveats: 

It makes the border between wm- and client-areas less clear. We then
have parts of the client area which belong to the wm functionality-wise,
while they will still be drawn by the client. The resize handles will change
their appearance along with the toolkit theme, not with the wm configuration.

If every app has to draw its own resize handles, we won't get the uniform
appearance a desktop should have. 

What happens if the client wants to provide resize handles, but the wm
doesnt support this feature ? Should the client have a second gui layout
to use in this case or will it have to live with some dead areas in its
layout ?

Some of these problems could probably avoided if the feature is hidden
in toolkits.

A different approach would be to have the wm draw the resize handles 
over the client window (in slight violation of the ICCCM) (isn't there
actually a wm which does this ?), and tell the app which parts of its
window are hidden. The app should then be offered a way to remove the
handles.


Don't get me wrong, I think this feature is worth thinking about. But
we should try to support it in a clean way. 



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