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. _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list