Re: Fwd: Draft 1

[Cristian Tibirna <ctibirna total net>]

On Tue, 22 Jun 1999, Matthias Clasen wrote:

> 
> > _NET_WM_MOVERESIZEGRIP
> > 
> > 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:
> > 
> 
> It makes the border between wm- and client-areas less clear. We then

??

Am I wrong if I say that you think at win95 resize decoration in SE
corner?

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

I don't think Matthias thinks of an actual zone/widget/element *drawn* on
the screen. It's more an active area (where mouse actions get special
meanings) which *eventually* can be visually signaled by some sort of
graphical element. The WM will offer the functionality (and maybe choose
to offer graphical hint too). The client could also *choose* to notice
visually the functional handle. That's why this Atom is needed.

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

Doesn't have to draw. But it could choose to. Uniformity is assured by
apps restraining themselves from offering the graphical hint there where
uniformity is a bigger issue than graphic verbosity.

> What happens if the client wants to provide resize handles, but the wm
> doesnt support this feature ? 

Well, that's why we want these specs. To be sure WM will support the
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 ?

?

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

Overkill. Not necessary, in the light of clarifications above.

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

Thanks for caring.

Cristian

Cristian Tibirna     : ctibirna@total.net     : www.total.net/~ctibirna
PhD Student          : ctibirna@gch.ulaval.ca : web.gch.ulaval.ca/~ctibirna
KDE contact - Canada :  tibirna@kde.org       : www.kde.org