Bug#763383: Add transparency option to gnome-terminal

Egmont Koblinger egmont at gmail.com
Sun Nov 2 11:48:29 UTC 2014


> Zerothly, there is no need for a patch; gnome-terminal supports
> transparency just fine.

It's not the same.  With the given patch, you get a translucent
background, but all other colors remain opaque.  With a WM/compositing
approach even the foreground colors, non-default background colors,
and the UI chrome (menubar, tabs, WM title bar) become transparent.
It's really not the same user experience.  Especially with the
foreground text becoming translucent, the result is in my opinion less
usable than with the explicit transparency patch.

> Firstly, this patch will *never* be accepted upstream
> Secondly, it relies on an undocumented feature of vte

Why not at least document the vte feature and committing to keeping
that, for the benefit of other vte-based apps?

> Thirdly, the actual patch presented here has several defects, chiefly
> the problem that it always forces an ARGB visual even when no
> transparency is in use. This may negatively impact performance and
> memory use.

Someone somewhere (can't remember who and where, sorry) pointed out
that quite a few other apps already always force ARGB without
problems.  As far as I remember, they pointed out that ARGB used to
have problems but it's not the case anymore.  Yet, if it's still an
issue, the patch should be further improved to handle this.

I myself have used g-t with this patch for about half a year now, and
F20/Rawhide also ships this.  I haven't found any reports yet that are
likely connected to transparency.

What are the other defects?

> Fourthly, the patch adds user-visible strings, but does not contain
> their translation

Isn't it one more reason for accepting the feature mainstream (maybe
behind a disabled-by-default configure flag)?  Translations would
appear at almost zero cost.

> Finally, there are many other terminal emulators that do support
> transparency (e.g., KDE's konsole); so if they want transparency, the
> user can simply choose to use one of them instead of gnome-terminal.

I have recently put tons of effort in improving gnome-terminal,
probably most significantly the rewrap-on-resize feature makes it
significantly better for me than most other terminals.  I'd hate to
tell our users "go use another terminal", that's not why I put so much
work in it.  I'd prefer my work to reach as many users as possible,
even those who insist on transparency.

> as an addendum: While the OP claims that the patch is already more
> widely used than just its originator (Fedora)

I'm not sure about Ubuntu's branches and stuff, but looking at
https://code.launchpad.net/~ubuntu-desktop/gnome-terminal/ubuntu and
https://launchpad.net/~gnome3-team/+archive/ubuntu/gnome3-staging
suggests to me that probably the patch is going to be included in
Vivid.

> In conclusion, it is my opinion that Debian should *not* add this patch
> to its gnome-terminal package.

I don't think I have a conclusion here :)  I think the best would be
if mainstream g-t accepted this feature, I can't see why ChPe is so
resistant, but he made it clear that the feature won't become
mainstream.  I'm not sure if all major distros shipping the patch and
pushing for adoption could make him change his mind.  Given this
situation, Debian should listen to its users, understand the pros/cons
of applying this patch and make whatever seems to be the best
decision.

cheers,
egmont



More information about the pkg-gnome-maintainers mailing list