Bug#763383: Add transparency option to gnome-terminal

[Egmont Koblinger]

Fyi: The transparency patch indeed did appear in Ubuntu Vivid.

On Sun, Nov 2, 2014 at 12:48 PM, Egmont Koblinger <egmont at gmail.com> wrote:

> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-gnome-maintainers/attachments/20141113/183c4de0/attachment.html>