Re: New hints for compositing window managers

[Fredrik Höglund <fredrik kde org>]

On Wednesday 25 November 2009, Denis Dzyubenko wrote:
> Hi Fredrik,
> 
> 2009/11/25 Fredrik Höglund <fredrik kde org>:
> > I want to propose a new set of window manager hints that lets a client
> > specify that a compositing window manager should extend the window frame
> > behind the client window.
> >
> > The _NET_WM_FRAME_OVERLAP hint is intentionally designed to be compatible
> > with the DwmExtendFrameIntoClientArea API on Windows, to make life easier
> > for cross platform toolkits and applications.
> >
> > When I discussed this idea with Carsten Haitzler on IRC a while back,
> > he convinced me that a single rectangle might not be sufficient for all use
> > cases.
> 
> That sounds like an excellent idea, I really look forward to having
> more control over window decorations. I know that Qt already uses
> DwmExtendFrameIntoClientArea for QWizard dialogs on Windows and it
> would be really nice to be able to implement it for X11 as well.
> 
> Is there anyone from a compositing manager camp interested in this?
> Will enlightenment or kde support this addition? (I can imagine that
> it might require a bit of effort to support this feature in a themable
> window manager).

The themes would have to be designed for it, but implementing it is
actually pretty easy. The window manager just draws the decoration
on the backbuffer, and then composites the client window over the
decoration.

I can't speak for others, but KDE will support this hint.

> Also it should be necessary to be able to figure out if the window
> manager supports this feature - probably we can add a new hint for
> _NET_SUPPORTED property.

The window manager would just add _NET_WM_FRAME_OVERLAP
to the list of properties in _NET_SUPPORTED. Applications that want
to use this feature will of course have to provide a fallback path in
case the window manager doesn't support it.

> Also, your suggestion doesn't say anything about the content of the
> window that is supposed to be transparent - should clients fill it
> with some value of just leave it uninitialized and the compositor will
> (somehow) take care of it?

The client just leaves the parts of the window where it wants the
decoration to "shine through" transparent.

> I also fail to see what will the compositor do with
> _NET_WM_FRAME_OVERLAP hint - lets say the client sets it to be
> -1,-1,-1,-1 - what does it mean? Will the window be opaque,
> transparent or semi-transparent with a blur like on Windows when using
> DwmExtendFrameIntoClientArea? I would expect the behavior whatever it
> is to be fixed so that clients can rely on it. Also, if it's the
> latter and the window will be "blurry" I actually fail to see how the
> compositor can implement this partual blur without knowing which areas
> inside the client window should be blurred (if I remember correctly,
> on Windows when using the DwmExtendFrameIntoClientArea function the
> client has to fill the transparent area with a specific color to tell
> the compositor where the blur should go).

The text in the patch attached to my original email explains in detail
how the values should be interpreted by the window manager. If all
values are set to -1, the window manager must extend the decoration
behind the whole window.

I agree that applications need more control over where the blur effect
is applied, but I think this is needed regardless of whether the window
frame is extended behind the client window or not. This is why I didn't
include a hint for it in my patch.

On Windows, applications can toggle the blur effect on and off for specific
windows, and define the region where the blur should be applied.
The region is defined in the struct passed to DwmEnableBlurBehindWindow.

Adding a _NET_WM_BLUR_REGION would give us the same functionality.

Regards,
Fredrik