GNOME Bugzilla – Bug 516885
Add RGBA support
Last modified: 2014-01-22 22:20:25 UTC
Patch coming to add RGBA support to Totem for GTK engines like Murrine which make use of it. I haven't tested it too extensively, but it works for Iacopo Masi, and runs OK with normal RGB for me.
Created attachment 105401 [details] [review] Add RGBA support to Totem
Created attachment 105403 [details] Screenshot of RGBA in action Here's a screenshot from Iacopo.
Well done. The Patch seems to work weel. Testers are welcome.
It should be enabled in GTK+ by default. If it's not enabled in GTK+ by default, I'm sure the GTK+ hackers will be able to tell us why it's not.
See also bug 515907.
Why it is not enabled? I guess because it will break some non-pure Gtk+ apps... Just imagine Firefox (so Gecko and XUL), Openoffice, WxGTK... But i've tried also with webkit (it seems broken too) Abiword, Gnumeric... So, before applying RGBA by default we should think about exceptions, workaround and special cases when RGB must be the fallback. I've discussed in IRC with thos, ebassi, benzea etc etc and we thought that a good way to implement RGBA could be adding a GtkSetting (rgba-colormap = TRUE, FALSE), mapping it to a Xsetting, and reading it in GtkWindow to enable RGBA colormap if is set to TRUE. But this needs work and a long discussion. I'm not sure it will be added in the next months... In the meanwhile, patching Gtk applications that are working rock-solid with RGBA colormap is the more secure & stable way. If in the future something will come in Gtk, then removing 3 lines of code it's not a problem :)
(In reply to comment #6) > But this needs work and a long discussion. I'm not sure it will be added in the > next months... So, lets not fix it? If someone sits down to do it and submit here and follow up with reviews, it can go in in as short as two weeks I bet. Don't be an apologist. Fix things properly. > In the meanwhile, patching Gtk applications that are working rock-solid with > RGBA colormap is the more secure & stable way. If in the future something will > come in Gtk, then removing 3 lines of code it's not a problem :) It actually is a problem. Five years from now, when new hackers and maintainers look at that code, they have no idea what it's supposed to do, or why is it there in the first place given that GTK+ should do it. Is it there to work around a bug? Someone needs to spend some of their valuable hacking time to clean up the mess. And that's just in one module.
(In reply to comment #7) > (In reply to comment #6) > > > But this needs work and a long discussion. I'm not sure it will be added in the > > next months... > > So, lets not fix it? If someone sits down to do it and submit here and follow > up with reviews, it can go in in as short as two weeks I bet. Don't be an > apologist. Fix things properly. > > > In the meanwhile, patching Gtk applications that are working rock-solid with > > RGBA colormap is the more secure & stable way. If in the future something will > > come in Gtk, then removing 3 lines of code it's not a problem :) > > It actually is a problem. Five years from now, when new hackers and > maintainers look at that code, they have no idea what it's supposed to do, or > why is it there in the first place given that GTK+ should do it. Is it there > to work around a bug? Someone needs to spend some of their valuable hacking > time to clean up the mess. And that's just in one module. > I have no time to work on it in the next two months... And I don't think you, or someone else, will do it for me.
(In reply to comment #8) > I have no time to work on it in the next two months... And I don't think you, > or someone else, will do it for me. It's not just for you really. If the feature is useful, someone will do it.
(In reply to comment #9) > (In reply to comment #8) > > > I have no time to work on it in the next two months... And I don't think you, > > or someone else, will do it for me. > > It's not just for you really. If the feature is useful, someone will do it. > That's the problem I think. I'm not sure that a lot of guys found it useful (since is just an eye-candy feature), and Gtk hackers like you are certainly busy with other things and probably they won't write that patch before gtk 2.14 (that will come in August I guess...). And that patch could cause other problems, see Firefox, WxGTK, Abiword Openoffice, GNumeric etc etc etc... So I'm sure, (show me if I'm wrong), that a change like this will never be accepted in time for 2.22 gnome release, and will probably be posponed to 2.24 (yes Gtk and Gnome are *separate* project, but we can think in 6 months releases). I know that patching few apps (I mean few not all of them) is not the most satisfying idea, and I've never said this will be the final solution. But actually, it's the saner way to have some transparency on our desktops from the next month. If you want to try an RGBA Gtk engine, just checkout http://svn.gnome.org/svn/murrine/trunk and use it under a composited environment
Isn't this an X problem? I just looked and Gdk uses the default visual and colormap that X11 gives it - see DefaultColormap() and DefaultVisual(). So if X were to hand out those as RGBA by default, Gtk apps would use it by default. If I'm right here, shouldn't we poke the X devs (at least their bugzilla) about it? (I'm not sure handing out an RGBA colormap/visual by default would work flawlessly in all X apps, but that's a different question. But I guess it'll work out the same way as transparency in panel applets - the ones that can't work with RGBA get fixed because people cry loud enough. :)) Gtk Engines would probably need fallbacks for the non-RGBA case anyway, so where it's set (app, Gtk, X) shouldn't result in any changes to the theme writers.
(In reply to comment #11) > Isn't this an X problem? > > I just looked and Gdk uses the default visual and colormap that X11 gives it - > see DefaultColormap() and DefaultVisual(). So if X were to hand out those as > RGBA by default, Gtk apps would use it by default. If I'm right here, shouldn't > we poke the X devs (at least their bugzilla) about it? > (I'm not sure handing out an RGBA colormap/visual by default would work > flawlessly in all X apps, but that's a different question. But I guess it'll > work out the same way as transparency in panel applets - the ones that can't > work with RGBA get fixed because people cry loud enough. :)) > > Gtk Engines would probably need fallbacks for the non-RGBA case anyway, so > where it's set (app, Gtk, X) shouldn't result in any changes to the theme > writers. > Actually, with Murrine engine there's the fallback for the normal RGB mode (basically is does the opposite :), it enables RGBA drawings when the colormap is RGBA)
(In reply to comment #11) > Isn't this an X problem? > > I just looked and Gdk uses the default visual and colormap that X11 gives it - > see DefaultColormap() and DefaultVisual(). So if X were to hand out those as > RGBA by default, Gtk apps would use it by default. If I'm right here, shouldn't > we poke the X devs (at least their bugzilla) about it? > (I'm not sure handing out an RGBA colormap/visual by default would work > flawlessly in all X apps, but that's a different question. But I guess it'll > work out the same way as transparency in panel applets - the ones that can't > work with RGBA get fixed because people cry loud enough. :)) The problem with forcing RGBA on all (broken) X apps will result in some of them shooting themselves in the foot as some are clearing their drawing area with something like #00000000. This in turn results in a pretty and useless border around a transparent window ;) But I agree, I'd rather break (as in fix) this in the lower part of the stack so the upper part is forced to apply a fix and play nice. Adding workarounds for broken apps should be a no-no in FLOSS.
(In reply to comment #11) > Isn't this an X problem? > > I just looked and Gdk uses the default visual and colormap that X11 gives it - > see DefaultColormap() and DefaultVisual(). So if X were to hand out those as > RGBA by default, Gtk apps would use it by default. If I'm right here, shouldn't > we poke the X devs (at least their bugzilla) about it? > (I'm not sure handing out an RGBA colormap/visual by default would work > flawlessly in all X apps, but that's a different question. But I guess it'll > work out the same way as transparency in panel applets - the ones that can't > work with RGBA get fixed because people cry loud enough. :)) > > Gtk Engines would probably need fallbacks for the non-RGBA case anyway, so > where it's set (app, Gtk, X) shouldn't result in any changes to the theme > writers. > I've poked the xorg guys: https://bugs.freedesktop.org/show_bug.cgi?id=14547
They seem to be interested not :/ .
I think you can double our chances of attracting people by posting the bug with a brief description to the appropriate mailing list. Practice teaches you that almost no one reads the bug reports in fd.o bugzilla.
Patryk, same applies for b.gnome.o, b.redhat.c, b.webkit.o and so others... Newbies use forums, which mostly are not read by developers, while developers mostly use mailing lists, which mostly are not read by newbies. And the circle is closed.
Jakub: Not really. If I post a bug in webkit's or gnome's bugzilla I almost immediately get a reply from the maintainer of the involved module. This is often not true for fd.o. It has nothing to do with new users and forums.
You can easily find very old bugs and feature requests here. Never red by anyone...
Back to the RGBA handling: It should be pretty simple to put this in GTK initialization code so it does not accept whatever X proposed but iterates over the list of supported modes and picks the most useful one (RGBA if supported). Applications using the toolkit usually don't rely on manually painting window contents so the worst issue to expect would be fixing the few custom widgets where authors decided to paint the thing using absolute colors. For example black is often expressed as "color = 0" which also sets the alpha bits to 0. I think that's a good idea to add visual selection to GTK at least to show the rest of the toolkits that moving to RGBA is a safe thing to do. Later we can convince Xorg guys to push the same things lower in the stack and GTK remains compatible with all releases of Xorg.
If I were to write a patch for this, it would probably replace the use of the DefaultVisual() macro in gdkvisual-x11.c by a small helper function that looks at an environment variable.
reject the totem patch since the bug was moved to gtk
I have little idea you might like or not. You discussed a bit about transparency being enable or disabled by default, so my little idea is to have transparency enabled by default where possible (when compiz running) and disabled by default where impossible. Additionaly "[x] transparency" would be added to "interface" tab in appearance capplet. I hope you're also doing something to make rgba possible for all apps, without touching their code. Currently, it seems that first rgba-enabled system is Vista, though GTK and Qt are rgba-enabled from earlier (there's no official announcement of stable theme)... Some (ofc. not the smartest) people will be saying that GNOME copied feature from Vista because noone payed big attentiont to building such theme/extending existing... D'oh.
Jakub: This bug is about enabling RGBA visuals in GTK+ by default, not about adding something to GNOME.
nvidia 177.67 fixes a lot of the glitches I had with RGBA + cairo. we should update the gtkstatusicon specification before 2.90, so to start testing in time for 3.0
Created attachment 118666 [details] [review] Optionally set rgba visual as default
As suggested above this patch adds an env variable GTK_RGBA_VISUAL and sets the system visual to an rgba visual if set. Please comment and I will improve the patch as necessary.
Adam: The patch seems to miss GDK_VISUAL () guard around screen_x11->system_visual. Also what happens in gdk_screen_get_system_colormap if RGBA was not requested?
Created attachment 118668 [details] [review] Add GTK_VISUAL guard If rgba is not requested then gdk_screen_get_system_colormap will create the system colormap from the DefaultVisual() using XCreateColormap. I'm not sure if this is the same as from DefaultColormapOfScreen().
Is there anything else required to see an effect than this patch? I applied the patch, installied murrine from svn and ran a few applications as 'GTK_RGBA_VISUAL=1 gtk-demo'. Nothing is different than before, I even tried a few different Murrine themes.
(In reply to comment #30) > Is there anything else required to see an effect than this patch? > > I applied the patch, installied murrine from svn and ran a few applications as > 'GTK_RGBA_VISUAL=1 gtk-demo'. Nothing is different than before, I even tried a > few different Murrine themes. > Sorry for the idiot question... ;D Are you running compiz or a composited window manager?
(In reply to comment #31) > (In reply to comment #30) > > Is there anything else required to see an effect than this patch? > > > > I applied the patch, installied murrine from svn and ran a few applications as > > 'GTK_RGBA_VISUAL=1 gtk-demo'. Nothing is different than before, I even tried a > > few different Murrine themes. > > Sorry for the idiot question... ;D Are you running compiz or a composited > window manager? No worries. I'm running xfwm4 with compositing and applications that request ARGB colour maps themselves work fine. And I'm also sure that I was running the right gtk. At best I could imagine it's something with Murrine but I don't see what I could have done wrong there either.
> No worries. I'm running xfwm4 with compositing and applications that request > ARGB colour maps themselves work fine. And I'm also sure that I was running the > right gtk. At best I could imagine it's something with Murrine but I don't see > what I could have done wrong there either. Check if you have the engine option 'rgba = TRUE' in the 'engine "murrine" { }' section of the gtkrc of the theme you're using
(In reply to comment #33) > > No worries. I'm running xfwm4 with compositing and applications that request > > ARGB colour maps themselves work fine. And I'm also sure that I was running the > > right gtk. At best I could imagine it's something with Murrine but I don't see > > what I could have done wrong there either. > > Check if you have the engine option 'rgba = TRUE' in the 'engine "murrine" { }' > section of the gtkrc of the theme you're using Again, yes, verified again just now, and even put it in my ~/.gtkrc-2.0 to make sure it's picked up. To no avail. One shouldn't think this is so hard.
Created attachment 120954 [details] RGBA test app I don't have a lot of time to spend on this at the moment but this is a test app i wrote when writing the patch. Could you try it out and see if the background is transparent. e.g. GTK_RGBA_VISUAL=1 ./main.py If you pass arguments it will manually set the colourmap to rgba.
For fun I tried applying the patch from comment #29 to gtk2 2.14.5-1ubuntu2 (jaunty). The RGBA test app works as expected: opaque when launched normally, translucent when launched with arguments, and translucent when launched with GTK_RGBA_VISUAL=1. Before applying the patch, I had successfully configured an RGBA Murrina theme with rgba = TRUE, and had translucency working in certain apps: gnome-terminal natively, gedit and rhythmbox with the appropriate plugins. However, applying the patch and setting GTK_RGBA_VISUAL=1 has not worked on any applications *other* than the test app, including gedit with the plugin disabled. Furthermore, it causes firefox to misdisplay, and makes rhythmbox and emacs crash with X errors.
A couple related bugs, here and downstream. The fact that people react fairly passionately to the requirement that each application support this independantly, leading to inconsistencies in appearance and design decisions, makes me really want to see a resolution to this... http://bugzilla.gnome.org/show_bug.cgi?id=515907 https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/274461
it doesn't work on gnome 2.28 (arch linux) :S either totem 2.26 or totem 2.28 seems like another package is doing something. I got this: The program 'totem' received an X Window System error. This probably reflects a bug in the program. The error was 'BadMatch (invalid parameter attributes)'. (Details: serial 910 error_code 8 request_code 1 minor_code 0) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the --sync command line option to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.)
*** This bug has been marked as a duplicate of bug 630217 ***