Re: New hints for compositing window managers
- From: Denis Dzyubenko <shadone gmail com>
- To: fredrik kde org
- Cc: wm-spec-list gnome org
- Subject: Re: New hints for compositing window managers
- Date: Wed, 25 Nov 2009 19:33:08 +0100
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
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
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
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?
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).
> I've therefore included a _NET_WM_FRAME_CLIP hint for specifying multiple
> rectangles. These two hints could be merged, but I think that the
> expectations are slightly different. It's less reasonable for the window
> manager to draw an inner frame around the rectangles specified in the
> property, since they they may form a complex region. Even when they don't,
> the client won't know how much space is needed between the rectangles in
> order for the window manager to be able to draw the frame.
> It's also unlikely that the client wouldn't need to update this property
> each time the window is resized. So for these reasons I prefer keeping these
> properties separate.
> There's also a _NET_FRAME_TEXT_COLOR hint set on the window by the
> window manager for use by the client.
> These hints provide an interesting contrast to the hints just proposed by
> Cody Russell, but they don't conflict or overlap.
] [Thread Prev