I see that the trend is to remove all terminal transparency due to VTE changes. Thus, I assume there is no chance to get back background transparency for roxterm in the (nearest) future?
It could be re-enabled for now, but I thought if it's going to be unsupportable in future we might as well get used to it. In current VTE it causes deprecation warnings in the compiler and I like to have a "clean" compile.
You might want to investigate gtk.css styling to see if you can achieve the same effect with that.
You seem to have CSS turned off.
Please don't fill out this field.
Thank you for your answer. As soon as I get some free time, I will have a look at gtk.css. If I manage to find something out, I will report it here.
this is really disappointing, c'mon to fix bug they're removing transparency just like that .. wrrrr
Several months ago when Gnome Terminal removed transparency I searched for an alternative to Gnome Terminal and found ROXTerm. At the time transparency still worked in ROXTerm. Now it seems both ROXTerm and Gnome Terminal have lost transparency due to the same change in the VTE dependency. Ouch! Now what? I guess I'll just wait to see how things turn out since ROXTerm has other features I like and require.
I've re-enabled the background options for now. You have to add --enable-deprecated-bg-opts to the mscript.py configure command if you're not using a Debian package.
Very nice. Does the transparency depend solely on roxterm itself now?
No, it still depends on the old functions in VTE, so it will probably break at some point in the future.
Note: VTE ended up not removing transparency. The API has changed though (there were several changes breaking backwards compatibility in the 0.37 series), you need to specify a background color that has an alpha channel.
Transparency was removed from gnome-terminal, a patch to bring it back is available at https://code.launchpad.net/~larsu/gnome-terminal/update-restore-transparency-patch . It gives an idea what needs to be done (gtk app_paintable and such). It requires a compositing WM.
Background image support (also known as faux transparency) was removed from VTE.
I'm a bit puzzled, because that patch uses the deprecated function vte_terminal_set_opacity. Is that a workaround for vte versions 0.34-0.36 while 0.37 supports transparency simply by using a background colour with an alpha channel?
Sure, sorry, you're right...
So, the patch I linked is against g-t-3.12/vte-0.36 which relies on the deprecated methods to set transparency.
I attach a version of that patch ported to g-t-3.13/vte-0.37 which uses the non-deprecated vte_terminal_set_colors method with a bg color that has an alpha channel.
Credits go to, in chronological order:
- Debarshi Ray (RedHat) creating the original version of this patch for g-t-3.12 which is now shipped by Fedora
- Lars Uebernickel (Ubuntu) for fixing this patch not to be transparent on the UI chrome (tab bar etc.)
- me for porting to g-t-3.13 :)
Vte 0.37 (unstable, stable 0.38 this autumn) breaks backwards compatibility at quite a few places. The lib installs with a different name (vte-2.90 vs vte-2.91), so 0.36 and 0.37 can be installed safely in parallel. Probably distros will ship the two versions in parallel for a while (in addition to the ancient Gtk+-2.x version vte-0.28).
Thanks for that. The existing version of roxterm seemed to work OK in Ubuntu trusty (vte 0.34.9) but in Debian unstable (vte 0.36.2) the background behind vte was black. Adding a "draw" signal handler based on the patch and calling gtk_widget_set_app_paintable seems to fix it for Debian without breaking in Ubuntu.
To keep things simple I just always call gtk_widget_set_app_paintable with GTK3. I would have had to change several function signatures to support calling it on demand, and the code is already overcomplicated.
I'll wait until vte-2.91 is available in Debian before supporting that, at which point I think I'll have to drop support for GTK2 so I can clean up the code a bit.