Re: RFC: new features

[Alexander Larsson <alexl redhat com>]

On Wed, 2012-01-18 at 11:56 -0800, Christian Hergert wrote:
> On Wed, 2012-01-18 at 09:47 +0100, Alexander Larsson wrote:
> > On Mon, 2012-01-16 at 13:08 +0000, Bastien Nocera wrote:
> > > On Fri, 2012-01-13 at 17:34 -0800, Christian Hergert wrote:
> > > > Hopefully this isn't getting old, but I'm sort of just throwing these
> > > > out there as I think of them.
> > > > 
> > > <snip>
> > > > BACKGROUND OPACITY
> > > > It would be nice to have the ability to alter the opacity of a window
> > > > without altering the opacity of GdkWindow'd widgets inside it. This is
> > > > useful for utility windows that float over a primary window. Right now,
> > > > you have to handle changes with the visual and/or screen and modify the
> > > > background yourself. This breaks possible theming and is tedious.
> > > > http://www.pixelmator.com/ is a good example of why this might be
> > > > useful.
> > > 
> > > Had that problem in the Wacom calibration screen. I wanted the elements
> > > to be opaque but on a translucent dark background. It wasn't possible
> > > without resorting to hacks (such as having 2 windows, one translucent
> > > with the black background, one with the opaque elements on a transparent
> > > background).
> > 
> > Can't you just make the window an RGBA window with a semi-transparent
> > color on the toplevel, but normal bg colors on the other widgets?
> 
> That sounds about right. If I understand the problem correctly, you have
> to make sure the visual supports RGBA and then update the GdkRGBA on
> style changes. My argument was that it would be nice if this was done
> for us with a "background-opacity" property between 0.0 and 1.0.

Thats not really possible. The way this works is that it sets an X
property that the compositor uses when painting the window pixbuf. The
compositor doesn't know what areas are part of some subwindow or
subwidget.