transparency does not work in gtk3

Bug #1599453 reported by Braden Kelley on 2016-07-06
36
This bug affects 6 people
Affects Status Importance Assigned to Milestone
Terminator
High
Unassigned
Arch Linux
Fix Committed
Undecided
Unassigned

Bug Description

Despite the code setting the alpha properly, transparency does not work for me in the GTK3 branch.

Changing the transparency setting makes no difference on my terminal, running from the tip of the gtk3 branch. It works fine in the GTK2 version, installed from apt-get.

I'm using Ubuntu GNOME 16.04 with gtk v3.0, libvte v2.91 on a Yoga 3 Pro. Graphics card is "VGA compatible controller: Intel Corporation Broadwell-U Integrated Graphics" with just the standard drivers that came with Ubuntu.

I've attached two configs with logs associated with each one:
 1) the default layout has a single profile, which has transparency turned on, titlebar off, and scrollbar turned off.
 2) the default layout has three profiles displayed.
  2a) The first is the same as in #1, with transparency turned on.
  2b) Next to it is a profile with transparency turned off, and with the titlebar on and scrollbar on the right.
  2c) Below both is a profile with transparency turned on higher, with a titlebar, and with the scrollbar on the left.

I'm playing around with the code trying to see if I can find a fix that will work for me. So far I haven't found anything that doesn't break something else.

Related branches

Braden Kelley (redbmk) wrote :

Continuing the discussion from https://code.launchpad.net/~redbmk/terminator/gtk3-fix-transparency/+merge/299224 here.

When I had the `self.get_toplevel().set_opacity(self.bgcolor.alpha)` in there as the only change, I noticed that it didn't work at all until I went into Preferences and clicked "Close". From the debug logs I realized that was triggering a reconfigure, but the first reconfigure when the terminal was created was happening before the window was ready. Taking it out of the init and moving it to after the window was created allowed transparency to work for me on the initial load.

If I do `self.set_opacity(self.bgcolor.alpha)` it seems to affect only the current window, but I end up getting a gray background. I think this is because the main window is still opaque. This makes the tabs still opaque, but the toolbars become transparent as well.

Stephen Boddy (stephen-j-boddy) wrote :

Hi Braden, a couple more possibilities:

1. Your GTK 3.0 will more likely be GTK 3.18 in 16.04, unless you have been installing PPA's or compiling your own GTK. Can you double check the version. I'm running 14.04 (previous LTS) with GTK 3.10, so perhaps default window/widget background behaviour has changed from not doing anything (i.e. empty and transparent) to filled with the theme's default background colour.

Gnome/GTK devs are notorious for making significant changes between 3.x releases. It is perfectly possible that someone decided "this is wrong" and just changed it. Then us downstream people end up chasing our tails trying to figure out why different people have different behaviour.

2. Another possibility is your theme. Perhaps it is making the background of the window solid gray instead of clear. Which theme are you using? (I'm using default Ubuntu Ambiance) And what happens if you try others? (This might take some effort to get them installed and set.)

I may have to spin up a 16.04 VM if none of this sheds light on things.

Changed in terminator:
status: New → Incomplete
Braden Kelley (redbmk) wrote :

Sorry, I wasn't sure how to find the version of GTK and did it wrong. Looks like it is actually 3.18.9-1ubuntu3.

I have the default Adwaita theme running. I tried switching to HighContrast and Numix, but neither of those helped. I also tried switching the "Global Dark Theme" switch on, which didn't seem to do anything. There's an option in the Tweak Tool for "Shell Theme" and it says "Shell user-theme extension not enabled". Do you think that's something I might need for transparency to work with the current code?

Another thing I just noticed - which might already be filed as a bug somewhere - is sometimes when I start up terminator running off the base gtk3 branch, now that I have it set to open 3 split screens with different profiles, is sometimes it will open them all in full-screen and one of them will have weird ASCII color codes displayed ($[[00m ) instead of just ($ ). When that happens I also need to click on the terminal to refocus it after closing the previous one.

I know from experimenting with the code that transparency is possible, but it does seem like they might have made some breaking changes between versions 3.10 and 3.18, so it might not be as simple as setting an alpha on the background color anymore.

Stephen Boddy (stephen-j-boddy) wrote :

Don't you have Ambiance? In the System Settings, Appearance panel?

I think the Shell Theme is referring to the desktop shell, i.e. Unity, Gnome, KDE etc.

That other issue description doesn't ring a bell. You should raise a separate bug. Try not to pollute bugs with unrelated issues, or it gets kinda confusing :-)

Yeah I'm getting very suspicious of GTK. Would be nice if others could confirm whether they have working transparency or not, and with which GTK version between 3.10 and 3.18. This might confirm/pinpoint a definite change in behaviour.

Now I'm thinking about it, I did briefly spin up a VM of beta 16.04 at some point. My memory is fuzzy, but I might have had no transparency too, but ignored it, because... well... Beta!!!

Braden Kelley (redbmk) wrote :

Hmm, no I don't even have an Appearance panel. I wonder if that's a difference between Unity and GNOME, or maybe something that's changed since 14.04. I just installed a "Customize Look and Feel" app that lets you change themes. It seems to have added some, but Ambiance isn't in there.

I ended up installing Ambiance (http://askubuntu.com/questions/369369/install-ambiance-theme-in-ubuntu-gnome) and tried it out, but still no transparency.

I also updated Gnome using the gnome3 ppa to supposedly get some newer features, but that didn't help either: https://launchpad.net/~gnome3-team/+archive/ubuntu/gnome3.

Braden Kelley (redbmk) wrote :

Just to update, I have a fix for this that sets the window background to be transparent instead of whatever the default is (some kind of gray color). This doesn't override the opacity of anything else, but it will make it so RGBA colors behave properly. The fix is to add a single line to window.py:

self.override_background_color(0, Gdk.RGBA(0, 0, 0, 0))

Braden Kelley (redbmk) wrote :

Oops...I wasn't done with that comment but I don't see a way to edit it.

I put that code after `self.set_visual(visual)` on line 377. However, I'm not entirely sure if that's the best place to put it.

The other problem is I found this documentation, which says that override_background_color is deprecated as of 3.16, so it's really only a temporary solution. It says instead to override the background using CSS. Is there anywhere currently using CSS in this code? I haven't found a good place to put that yet.

https://lazka.github.io/pgi-docs/#Gtk-3.0/classes/Widget.html#Gtk.Widget.override_background_color

Braden Kelley (redbmk) wrote :

OK, sorry for all the messages. I have a fix using CSS. Could you please make sure it doesn't break anything else? I checked the preferences screen, and am using the three profiles in this config to test.

I'm not really familiar with other widgets (like Notebook) so hopefully the changes are localized enough. At first I was using the `GtkWindow` css selector but that made the background in the preferences transparent, which was weird. So instead I added a class to windows and used that as a selector. If something that shouldn't have transparency uses the Window class from window.py then that might be an issue.

https://code.launchpad.net/~redbmk/terminator/gtk3-fix-transparency/+merge/299414

Cool. I'm a bit busy to give it a thorough test right now, so perhaps later.

Yes, the constantly changing set of deprecations and new/different ways of doing things is a bloody annoying source of frustration with GTK. It may make perfect sense but it means extra overhead trying to figure out how to do things out all over again.

Never, ever apologize when you post multiple messages showing your working, especially when you come up with fixes. It educates everyone, including me :-)

I see you found a bit of CSS I used to fix the splitter sizes in GTK 3. Nice neat looking patch you've added. The Preferences window going transparent is understandable, as it is not a modal dialog or anything, just a bog standard GtkWindow, so if you set the style on that class, the Preferences window would also inherit it, and hence the transparency. (Probably also the Custom Commands plugin prefs window too.) But you've figured out the right way to fix it with the assigned custom class. Two things I might suggest:

1. A more specific classname. I'm thinking of the future where the whole interface is themed using css, and there are stylings defined in the GTK themes related to terminals (i.e. gnome-terminal). Maybe we would want to follow that generic scheme, and that name would conflict. I'm not sure how the CSS hierarchy works, but I think it might end up looking something like:

.gnome-terminal-window .terminator-terminal-window

This is all currently conjecture and guess work, so ignore the hierarchy stuff for now, but maybe the class name can be changed to terminator-terminal-window? What do you think?

2. Is there a CSS property that just changes the opacity/alpha? If compositing is not working then your RGBA would override the theme, and the background would be black. If the theme uses padding/spacing around widgets this would be visible and probably ugly.

Download full text (5.1 KiB)

The BEM methodolgy (https://en.bem.info/) seems to be gaining popularity.
Might have classes like .terminator-terminal__window--transparent or
whatever. That would help ensure classes are clear and unique, although
verbose. At this point though, probably just changing it to
.terminator-terminal-window would be fine as it could be changed in the
future if you decide to write the whole styling in CSS.

It looks like the "opacity" CSS property is supported, but it doesn't work
the same way. In my case the background is black and the foreground goes
invisible - so at 0 opacity the whole window is just black, and at 0.5
opacity the foreground can only be partially seen - you still don't see
through the window to anything below. I think this is because all the child
elements inherit the opacity of the parent (
https://developer.mozilla.org/en-US/docs/Web/CSS/opacity) - but regardless,
the background of the window is still opaque.

In browsers if a property isn't supported it is just ignored. I'd assume it
works the same here, so if rgba isn't supported it should just revert to
the default. For example, you could set 'background-color: rgb(...);
background-color: rgba(...);' and if rgba is supported it would use that,
otherwise it would use the rgb. If you don't have the first declaration it
would just use whatever is the default. I don't know how to go about
testing this though, since transparency is supported on my machine. AFAIK
there's no way to set just the alpha part of a background-color.

On Thu, Jul 7, 2016 at 4:45 PM Stephen Boddy <email address hidden>
wrote:

> Cool. I'm a bit busy to give it a thorough test right now, so perhaps
> later.
>
> Yes, the constantly changing set of deprecations and new/different ways
> of doing things is a bloody annoying source of frustration with GTK. It
> may make perfect sense but it means extra overhead trying to figure out
> how to do things out all over again.
>
> Never, ever apologize when you post multiple messages showing your
> working, especially when you come up with fixes. It educates everyone,
> including me :-)
>
> I see you found a bit of CSS I used to fix the splitter sizes in GTK 3.
> Nice neat looking patch you've added. The Preferences window going
> transparent is understandable, as it is not a modal dialog or anything,
> just a bog standard GtkWindow, so if you set the style on that class, the
> Preferences window would also inherit it, and hence the transparency.
> (Probably also the Custom Commands plugin prefs window too.) But you've
> figured out the right way to fix it with the assigned custom class. Two
> things I might suggest:
>
> 1. A more specific classname. I'm thinking of the future where the whole
> interface is themed using css, and there are stylings defined in the GTK
> themes related to terminals (i.e. gnome-terminal). Maybe we would want
> to follow that generic scheme, and that name would conflict. I'm not
> sure how the CSS hierarchy works, but I think it might end up looking
> something like:
>
> .gnome-terminal-window .terminator-terminal-window
>
> This is all currently conjecture and guess work, so ignore the hierarchy
> stuff for now, but maybe the class ...

Read more...

Braden Kelley (redbmk) wrote :

Alright, I made one more change after discovering that having a solid background in vim makes it so the screen is no longer transparent. If I use "NONE" for the background in vim, the colorscheme looks weird. However, if instead of setting `self.bgcolor.alpha` I call `self.vte.set_opacity` with the same values (terminator.py lines 680 and 682) then vim will also be transparent according to the settings in terminator, and the colorscheme stays the same. I think setting both the alpha and the transparency would cause double transparency - (i.e. setting it to 50% would cause it to be only 25% opaque).

Now, I'm not sure if this will be desired behavior or not for most people. As far as the pull request is concerned, I can leave it as is, but at least for my purposes setting the opacity rather than the background alpha works much nicer for me. It's your call obviously. Maybe a setting in transparency would be helpful (e.g. a radio switch for "window transparency" vs "background transparency")?

Braden Kelley (redbmk) wrote :

Now I'm also finding that having multiple tabs open re-breaks transparency. There's probably something over the main window that doesn't fit the .terminator-terminal-window selector.

You can test the following "hack":
Run terminator using the following:

GTK_DEBUG=interactive terminator

In the CSS tab (at the top) You can insert the following CSS snippet:

---8<---
.notebook.header {
    background-color: @bg_color;
}

.pane-separator {
        background-color: @bg_color; }

/* need a searchbar classname, just using horizontal works, but breaks other areas */
.searchbar {
        background-color: @bg_color; }

/* Haven't figured out this properly yet. None-obvious breakage in Ambiance. */
/* .scrollbar:hover:not(.slider),
.scrollbar.dragging:not(.slider) {
    background-color: alpha(@scrollbar_track_color, 0.4);
}

.scrollbar {
        background-color: @bg_color; }
*/
---8<---

This will fix the tabs and separators. The searchbar container needs a class properly assigning so we can properly address it. The scrollbar I have't gotten to the bottom of. These objects also need some proper class names assigning so we are only targeting the correct widgets in Terminator.

OK, So I've been having a play with the CSS styling. I've built upon Braden's work which you can see in the additional attached branch. This is a rough and ready POC. But under Ambiance most of the broken backgrounds are fixed. It also includes a cribbed start to making the tab styling follow the GNOME-Terminal tabs under the Ambiance theme. It also includes a fix for the Adwaita overlapping hover area. Stuff still to do:

+ I'm not targeting the specific widgets in just the terminal window yet. That's down to selectors and classes and stuff. For an example under the Ambiance theme the tabs in Prefs get styled like the ones in the terminal window. Need to understand how it is done in GNOME-Terminal, because there it looks like it's pure magic, based on C widget names. Not sure if this works the same in Python. Compare the /usr/share/themes/Ambiance/gtk-3.0/apps/gnome-terminal.css with the newly added terminator.css - we need to get closer to the tighter selectors they have.

+ Ambiance: The very top left and right pixels in the tabs header are still transparent.

+ Ambiance: The Ambiance theme related tweaks file needs to be pulled in as a resource from the appropriate theme directory, instead of brute forcing it in regardless of theme.

+ Ambiance: When hovering over a scrollbar there is a small sliver that becomes transparent.

+ Ambiance: Rest of the tab positions (other than top) need fixing up to also follow the top style.

+ Adwaita: The tabs are transparent still, although we are setting background-color: @bg_color; Maybe Adwaita does not define @bg_color? What does it use instead?

+ Adwaita: There's an unwanted outline in the titlebar.

I really am making this up as I go, so if anyone with more expertise on CSS theming/styling can offer help, it will be greatly appreciated.

Changed in terminator:
status: Incomplete → Triaged
importance: Undecided → High

+ Adwaita: The tabs are transparent still, although we are setting background-color: @bg_color; Maybe Adwaita does not define @bg_color? What does it use instead? DONE

Turns out there are "public" and "private" colour definitions. I was trying to use an internal Ambiance colour (@bg_color), which is why it broke on Adwaita. Needed to switch to @theme_bg_color.

Also tweaked so fix for Adwaita is always applied, not just when splitter handle size is overridden.

Oh I should also mention that I've disabled the stylistic stuff I sto... *cough* borrowed(?) from GNOME-Terminal Ambiance for making the tabs look better. It looks like crap under Adwaita (duh!). So until I figure out a way to do theme specific stuff properly, better to just disable it. If I don't the pitchfork squad will be after me.

Braden Kelley (redbmk) wrote :

OK, I've been playing with your changes and I think we're really close.

It wasn't always transparent - for applications like vim it would still be opaque. I fixed that by changing a couple lines in terminal.py (see the diff below).

Then, I didn't know you could import a css file, so I think that is way cleaner than the inline css I had done before. The css that seems to work is below as well - I simplified what you had a little bit and made a couple additions to get it to work with the transparency changes I made in terminal.py. I think we're nearly there - I noticed a few issues with some themes other than what you had mentioned.

Here are the themes that are on my system in the debugger menu: Raleigh, Numix, Radiance, Adwaita, HighContrast, and Ambience. Raleigh doesn't actually show up in my system-wide themes, it just shows up in the interactive debugger...not sure what it is.

As far as I can see so far, these are the issues with them:

Raleigh:
 * Doesn't like @theme_bg_color. Instead it seems to prefer @bg_color.
 * Has a thin, transparent line around the whole frame.

Numix:
 * The titlebar is no longer red - it appears white, which makes the text unreadable.

Radiance:
 * The scrollbar has a weird transparent strip

HighContrast:
 * The scrollbar base is transparent when window is not focused

Ambiance:
 * Nothing new besides what you noticed - the scrollbar issue seems to be a related to the issue with Radiance and HighContrast.

terminator.css
==============

.terminator-terminal-window,
.notebook {
  background-color: transparent;
}

.pane-separator,
.terminator-terminal-searchbar,
.notebook.header {
  background-color: @theme_bg_color;
}

terminal.py
===========

diff --git a/terminatorlib/terminal.py b/terminatorlib/terminal.py
index 0ee4851..c5471e6 100755
--- a/terminatorlib/terminal.py
+++ b/terminatorlib/terminal.py
@@ -678,9 +678,9 @@ class Terminal(Gtk.VBox):
             self.bgcolor.parse(self.config['background_color'])
·
         if self.config['background_type'] == 'transparent':
- self.bgcolor.alpha = self.config['background_darkness']
+ self.vte.set_opacity(self.config['background_darkness'])
         else:
- self.bgcolor.alpha = 1
+ self.vte.set_opacity(1)
·
         factor = self.config['inactive_color_offset']
         if factor > 1.0:

Ok first thing is that we can't switch from bgcolor to set_opacity in terminal.py. set_opacity affects the *whole* VTE widget, making the foreground text transparent too. This is a non starter. If Vim looks strange with this then that is a problem with Vim, I think. You can attache a screenshot of what Vim is doing, but if it is a case of Vim forcing areas to solid colour then that suggests to me that that is part of the sytax/theming in Vim, and I don't think making all the text semi-transparent is the answer to that.

I'm still figuring out the bit about loading in css, looking at examples about how to pull in files from resource:/path/theme/file.css so I haven't finished that bit.

As for my quick spin through a variety of themes:
Adwaita

Ambiance
Breeze
Breeze-Dark
Clearlooks-Phenix
Greybird
HighContrast
Numix
Radiance
Yuyo (Yuyo-Dark is identical)

Damn! Hit tab and space and prematurely posted. (Hey, Launchpad? How about an edit feature?)

+ is my observations, * is yours.

Adwaita
  + Thin outline box around the titlebar label.

Ambiance (Radiance is identical)
  + When hovering over a scrollbar there is a small sliver that becomes transparent. (In actual fact the whole thing is meant to be transparent as per GNOME-Terminal under Ambiance.)

Breeze (Breeze-Dark)
  + Thin outline box around the titlebar label.
  + When there is no tabs the scrollbar is part transparent. With tabs it's solid.

Clearlooks-Phenix
  + White box/background around the titlebar label

Greybird (No visible issues)

HighContrast
  * The scrollbar base is transparent when window is not focused
  + The above doesn't happen if the window has tabs.

Numix
  * The titlebar [label] is no longer red - it appears white, which makes the text unreadable.

Raleigh (this is the very old fallback, now deprecated/removed)
  + Broken all over the place, but won't be looking to fix this.

Yuyo (Yuyo-Dark is identical)
  + The titlebar label is no longer red - it appears white, which makes the text unreadable.
  + The height of the tabs changes when the window loses focus.

OK, so there's some common items there to be thrashed out. Then for quirky theme specific stuff (or theme specific customisations like GNOME-Terminals tabs under Ambiance) I'll need to come up with a loader routine to pull in a file in the same way that GNOME-Terminal pulls in:
/usr/share/themes/Ambiance/gtk-3.0/apps/gnome-terminal.css

Braden Kelley (redbmk) wrote :

Ah, fair enough about the transparent text. I think you mentioned that before and I totally forgot. I hadn't pushed that change before because of that but I was running with it locally. I made a few tweaks to my vim colorscheme to get a transparent background, so it looks great in there as well, and probably the right way to go.

Braden Kelley (redbmk) wrote :

Oh, I also ran into an error with loading the css. The path seems to be relative to where you run the script, so "terminatorlib/terminator.css" will cause terminator to fail to load unless you run from the root of the code (i.e. it won't work from a desktop shortcut). I like the idea of keeping the css in a separate file, but we would need a way to find the resource. I'd imagine there's some way to do that in the GTK api...not sure though

Committed revision 1642.

Add theme specific css file loading (from terminatorlib/themes and ~/.local/share/themes), move Adwaita fix into own file.

Should specify that only one file gets loaded, with the .local file taking precedence.

I've used the folder structure commonly used under /usr/share/themes. This is in case we decide to move things under there. I haven't made my mind up yet, but this implementation will do for now.

Word of warning. If you are switching themes, and using custom css, then we currently don't react to the theme change warning. This can result in a Frankenstein mix. Just open and close the prefs to force a reconfigure, and the correct custom css will be loaded.

Committed revision 1643.

One line to fix the top left and right corners of the tab header background for Ambiance customisation.

OK, so I'm a bit stumped at this point. Ambiance uses these horrid skinny scrollbars, but there might be other themes that rely on this kind of trickery. You can see in the attachment how ugly they look with Terminator (left two, window active and scrollbar hover) and how they should look with GNOME-Terminal (right two).

I have a way of fixing it (setting the background of the HBox containing the terminal and the scrollbar) to match the background of the terminal.

Unfortunately getting the background of the vte terminal and setting the background of scrollbars using CSS as I've been doing it is a non starter. A single window might have multiple profiles with different colours and levels of alpha. Instead I need to set the background of individual widget instances. It seems that as usual the GTK devs decided that anything simple is bad, and anything that looks like a simple function call is deprecated. Any info/examples I've found so far seem to be about creating CSS that using selectors covers all widgets with that class. I'm at the point where the only thing I can think of is to start creating a CSS class per profile, and setting the individual widgets class names to correspond to the profile.

Or does anyone else have better any better ideas/experience?

Braden Kelley (redbmk) wrote :

This should fix the scrollbars in Ambiance:

.vertical.scrollbar:hover:dir(ltr),
.vertical.scrollbar.dragging:dir(ltr) {
  margin-left:0;
  border-left:2px solid @dark_bg_color;
}

.scrollbar.dragging:not(.slider),
.scrollbar:hover:not(.slider),
.scrollbar:not(.slider) {
  background-color: @dark_bg_color;
}

Braden Kelley (redbmk) wrote :

Adding .notebook.header to the list of selectors with @dark_bg_color makes the tabs look better as well...and more in line with GNOME Terminal.

Looks like those rules help out with Radiance as well, but then Radiance also needs this:

.notebook tab .button {
  background-color: transparent;
}

Braden Kelley (redbmk) wrote :

oops, adding .notebook.header breaks the preferences window...but you could use:

.terminator-terminal-window .notebook.header

You could also add some transparency to the background of the scrollbar, sort of like "background-color: alpha($color, $percent)", but I think it'd be really hard to get it to match up exactly with the terminal. Also since each VTE can have different transparency, that could get really tricky.

Braden, are you pulling the new branch I attached to this bug report? You make the suggestion about setting the notebook header to use dark_bg_color, and I've already done that. The Terminator tabs under Ambiance are now identical to the GNOME-Terminal ones, not just similar.

Your scrollbar css was helpful, I can at least get a satisfactory looking scrollbar using it :-) Unfortunately, as you've realised, that only works for a single profile colour/alpha combination. This is why my plan changed to modifying the background of the parent HBox widget. That is much more simple and avoids trying to modifying the scrollbars that have more complicated css. It currently still requires creating per profile css fragments to handle the colour/alpha combos, and modifying the HBox class name on reconfigure. If I could figure a way to modify *individual instances* of a widget, I could use the terminal reconfigure function to copy from the vte settings to the HBox, avoiding having per profile css. But like I say, every single damn function that does it simply is marked as depreacted in the gtk docs. Grrrr.

I'm aware of breakage going on in the prefs window. I just wanted to get it looking good in the main window before I start refining it down to not modify other ones. Admittedly I hadn't thought to use inheritence like you show, so that's useful.

Based on this I've...
Committed revision 1646.

Which fixes prefs, and adds the theme specific Radiance file to give GNOME-Terminal like tabs.

Braden Kelley (redbmk) wrote :

I thought I had pulled the latest this morning when I looked at it. I just did a fresh "bzr branch lp:~stephen-j-boddy/terminator/gtk3-fix-transparency".

Yeah, you gotta keep pounding F5 ;-) Another two commits already :-D

So I think it's not too far off. Things to do:

+ Add a checkbox to enable/disable custom per theme styling. (Fixes are always applied.)

+ Figure out how to make that damn Ambiance/Radiance scrollbar transparent as desired, leading to...

+ Find a fix for those themes whose scrollbars rely on a solid theme coloured background, like Breeze and High Contrast.

After that I'd be pretty happy to merge it into the main gtk3 branch. I'd expect those using a theme to raise bugs or provide css fixes for any lingering issues, which should be easier now that we're getting a grip on how this house of cards works.

Braden Kelley (redbmk) wrote :

I'm a Bazaar newb, so maybe I'm doing something wrong. Earlier I had done a fresh bzr branch, then just now I did a "bzr merge && bzr commit -m 'merge changes'" in that branch. I'm still seeing the space above the tabs as being a different color, and it looks different than gnome terminal. If I add the following CSS, then I get a dark background.

.terminator-terminal-window .notebook.header {
  background-color: @dark_bg_color;
}

bzr branch :will create a local branch of a Launchpad branch
bzr pull :will go back to the original Launchpad branch and pull down any new updates
bzr log | less :will show the last commit number of your branch which you can compare against the original branch in Launchpad.

As you can see here: https://code.launchpad.net/~stephen-j-boddy/terminator/gtk3-fix-transparency
You should have revision 1648 as the topmost entry in your log.

If you've committed changes to your local branch the local copy is said to have deviated, and you can't pull new updates from the original. Looking at what you've done I suspect by using commit you have deviated, and now it can't get the new updates somehow, but without literally having a step-by-step with all your commands, it's hard to say.

If you have rights to commit to the the original (in this case I own it, so you don't) then you should do a pull from the original before committing changes to your local branch. This way you can then use...
bzr push :will push new commits from local branch to the original branch, assuming no deviation has occurred.

If you look in gtk3-fix-transparency/terminatorlib/themes/Ambiance/gtk-3.0/apps/terminator_styling.css lines 8-13:

  8 .terminator-terminal-window .notebook.header {
  9 border-width: 0; /* set below depending on position of tab bar */
 10 border-color: shade (@bg_color, 0.82);
 11 border-style: solid;
 12 border-radius: 0px 0px 0px 0px;
 13 background-color: @dark_bg_color;
 14 }

As you can see, exactly the same declaration. You should not need to set it again. Let me know if that gets tabs looking all ship-shape for you.

Committed revision 1649.

This fixes those wacky transparent scrollbars for Ambiance.

I do have one strangeness with this still. If the profile is set to use the colours from the system theme, then I get a nasty effect. When configuring a terminal later on, we retrieve the system colours from the vte widget. But at the time we are generating this CSS, no widgets have been created. I tried initing an unused, unseen vte terminal, but it seems that defaults to giving back black, and not whatever the system colour is.

Committed revision 1650.

Fixed Radiance scrollbars as per Ambiance, and also remove oversized areas on splitter handles from Breeze.

Braden Kelley (redbmk) wrote :

I saw that line in terminator_styling.css, but it looks like for me it was being overridden by the inline css that does this:

.terminator-terminal-window .notebook.header {
    background-color: @theme_bg_color; }

If I move things around so that all the inline css is done first, then the css file overrides it properly. Take a look at this diff (I'm on revision 1650 right now)

Braden Kelley (redbmk) wrote :

I'm not seeing the nasty effect you're describing by having when set to use colors from the system theme.

I was playing around with this some more yesterday and realized we also need this: to highlight the track bar.

.scrollbar:hover:not(.slider) {
  background-color: alpha(@scrollbar_track_color, 0.4);
}

What's the difference between terminator.css and terminator_styling.css? Looks like terminator.css just has the scrollbar stuff in it, but terminator_styling has everything else. Couldn't it all just be in a single file?

See the attached screenshot. If your systems background colour is black then it will look fine. I'm not sure why mine is set to white, or how/when it got changed, but that is when it becomes a problem as you can see in the screenshot. It only happens for system theme colors as I explained in my previous comment.

I've added the scrollbar track highlight snippet.
Committed revision 1651.

terminator.css is for fixes. Stuff that has to go in to fix rendering problems (Ambiance transparent scrollbars) or functionality (Adwaita oversized hover area).

terminator_styling.css is for optionally modifying looks to improve the appearance for purely aesthetic reasons (Ambiance notebook headers). Some may dislike these kind of tinkerings and prefer an unadulterated default theme, so by keeping it separate we can give the purists the ability to turn of these stylings.

I rebooted overnight, and now strangely the notebook header background is not working?!? Still investigating...

Braden Kelley (redbmk) wrote :

I was just thinking about the background, and realized it's because the last css bit is in an if clause (if self.config['handle_size'] etc) and it overwrites the previous css string. However, it then adds the css as a new provider outside the if clause. If you didn't enter the if clause, it will be the same as before, but since this is happening after the terminator.css and terminator_styling.css files are imported, that css will take precendence.

So, that diff I sent should fix it, because it changes the if clause to append to the css, and then only sets the provider once, before any of the css files that will override it.

Gah!!! Thank god for the many eyes theory making all bugs shallow. I was spinning around trying to figure out why my backgrounds were working one minute, then not the next. I'd been using a custom size, and then turned it off. Your explanation was the answer. OK, So I have a fix that is similar, but different to yours. I explicitly want the sizing to be the last thing set, so that theme specific CSS cannot override it (user always has the last word).

So instead of moving it up, I just init the string back to "" and append the sizing if set. Totally fixed now. Thanks for the insight :-)

Committed revision 1652.

Oh and apologies for either missing, or misunderstanding comment #37. Not sure what happened there :-)

Braden Kelley (redbmk) wrote :

No worries. I'm just glad you're working on this and you're progressing through it so fast. I was messing around with getting the scrollbars transparent last night and ended up doing something similar to what you did with setting a separate background color per terminal, but your solution is more solid than where I was headed.

For me, I get a black scrollbar if I use system colors. If I set the background color manually I get whatever color I set it to.

However, I noticed in GNOME Terminal I get a purple scrollbar when I use system colors (with the Ambiance theme). I'm not sure where it's getting that color from, but it does seem like the right colors for that theme. I'm digging around in the gnome-terminal source and looking online for other css variable names but not having much luck.

Braden Kelley (redbmk) wrote :

Ah, I found it. The color it uses for the terminal background is
@terminal_bg

On Sun, Dec 11, 2016 at 8:49 PM Stephen Boddy <email address hidden>
wrote:

> Oh and apologies for either missing, or misunderstanding comment #37.
> Not sure what happened there :-)
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1599453
>
> Title:
> transparency does not work in gtk3
>
> Status in Terminator:
> Triaged
>
> Bug description:
> Despite the code setting the alpha properly, transparency does not
> work for me in the GTK3 branch.
>
> Changing the transparency setting makes no difference on my terminal,
> running from the tip of the gtk3 branch. It works fine in the GTK2
> version, installed from apt-get.
>
> I'm using Ubuntu GNOME 16.04 with gtk v3.0, libvte v2.91 on a Yoga 3
> Pro. Graphics card is "VGA compatible controller: Intel Corporation
> Broadwell-U Integrated Graphics" with just the standard drivers that
> came with Ubuntu.
>
> I've attached two configs with logs associated with each one:
> 1) the default layout has a single profile, which has transparency
> turned on, titlebar off, and scrollbar turned off.
> 2) the default layout has three profiles displayed.
> 2a) The first is the same as in #1, with transparency turned on.
> 2b) Next to it is a profile with transparency turned off, and with the
> titlebar on and scrollbar on the right.
> 2c) Below both is a profile with transparency turned on higher, with a
> titlebar, and with the scrollbar on the left.
>
> I'm playing around with the code trying to see if I can find a fix
> that will work for me. So far I haven't found anything that doesn't
> break something else.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/terminator/+bug/1599453/+subscriptions
>

Yeah, they've effectively hard coded that Ambiance purple into the gnome-terminal.css file. Presumably if you could find the system background colours in dconf/gconf and tweaked them, it would probably start looking crap in gnome-terminal too. I can't however find a way of doing this, or of proving the theory.

But... I fixed it!!!
Committed revision 1653.

I thought I had an inkling what was going on and I was right. Because the window wasn't realized it wasn't properly setup yet with the correct values from the system. I created a dummy window/vte and realize it, and hey presto, the values are correct! Yay! Note that the window being realized doesn't display the window to the user. As soon as we have the background value, we delete the window/vte.

Getting real close to a merge now.

+ Add a checkbox to enable/disable custom per theme styling. (Fixes are always applied.)

+ Start listening for a theme change signal so we can force a reconfigure without having to mess about opening prefs to trigger it.

+ Other themes will need fixups (i.e. Breeze and High Contrast scrollbars) which I may or may not do.

Braden Kelley (redbmk) wrote :

It looks like gnome-terminal.css does actually do a "define-color @terminal_bg #300a24". The weird part was when I did "background-color @terminal_bg" in the debugger I got the right color, even though in theory it's not defined.

I just pulled your latest changes and it actually looks weird to me - I get a bright white background. I guess if your terminal is white, that looks OK, but on a black background it looks pretty weird. I get the same thing if I use the theme colors or not.

If I add the following CSS it looks just like gnome-terminal. Again, I'm not sure why @terminal_bg works, but it does - maybe because I have GNOME Terminal open also?

.terminator-profile-default {
  background-color: @terminal_bg;
}

Braden Kelley (redbmk) wrote :

The white background when I don't have "use theme colors" selected is because I had my background set to white. If I change it to black, for example, it does work. However, when I have it set to use theme colors I get white, which seems odd.

Waaaahhh! My head's beginning to spin a bit. It all works exactly how I'd expect now at my end. Pull the last commit I just did, just to be sure we're in sync.

There /should/ be no "cross-talk" for want of a better phrase between Terminator and GNOME-Terminal. They are loading different files entirely. But yes, I can also use that value, which is very odd unless there is some kind of shared global defined color cache. I really don't know enough about how this all hangs together to make a comment on that. But for now, let's not add CSS in the debugger. It's good for figuring out the structure, but we can't directly use those rules anyway, because different people have different system colours. (In particular that @terminal_bg has no alpha.)

Just so we're clear... You are not running terminator from within terminator, right? Because this will cause issues. Terminator runs as a daemon now by default, to reduce resource usage, so the new launch of terminator will ask the original launch to open a new window. This can mean you thinking you are running new code, but in fact you're not. This can be very confusing, esp. if you run the system installed software that doesn't have a bunch of fixes, and then try to test them. You either need to disable DBus, or run terminator with the -u flag to avoid this problem.

Either way, set your default profile to use the system colors, then quit all instances of terminator. Apply the attached diff.

Use gnome-terminal or similar to run terminator (debug/inspection is not necessary). You should see three lines of output like this:
During terminator reconfigure: #ffffff
During terminator reconfigure: #ffffff
During terminal reconfigure: #ffffff

Can you post yours back?

Braden Kelley (redbmk) wrote :

Now I'm really confused. I tried forcing @terminal_bg to be the background in the code. Then it was the same color as gnome terminal. Out of curiosity I changed the definition in gnome-terminal.css to:

@define-color terminal_bg red;

And sure enough, I got a red background. I don't understand how or why it's pulling that from gnome-terminal.css. I even tried changing that from within terminator, without gnome-terminal running, then restarting terminator, and it still affected the color. So, regardless of whether gnome terminal is or was ever running, changing gnome-terminal.css seems to affect terminator's css definitions.

Also, I tried the changes you suggested (I'm now on rev 1654 with the applied patch) and I always get #ffffff.

Braden Kelley (redbmk) wrote :

And yeah, just to be clear I was either running terminator from gnome-terminal, or from a desktop link I made that runs it from the code directory. Either way, I made sure terminator was closed before opening it again.

And you got both "During termin>>>ator<<< reconfigure" and "During termin>>>al<<< reconfigure" lines with #ffffff?

Because if so, then I'm stumped. Shortly after the terminal line, the terminal colors are set, including the background, which should be white, with whatever alpha value you have set.

If I've understood you right, you have "Use colors from system theme" checked, and yet you have a black (possibly partially transparent) main background area, with the white scrollbar trough.

BTW, what version of libvte are you using?
dpkg -l | grep libvte-2.91

It should be somewhere between 0.30 through 0.46.

Committed revision 1654. (Reconfigure on gtk-theme-name change)
Committed revision 1657. (Toggle to deactivate extra styling)
Committed revision 1658. (Fixes for Breeze and HighContrast)

Braden, I think I'm pretty much done with this, and am ready to merge it into the main gtk3 branch, as it needs wider testing as it seems to just be you and me at the moment. There's just your peculiar issue that I can't figure out, but maybe more eyes on it might prompt someone.

Changed in terminator:
status: Triaged → Fix Committed
Braden Kelley (redbmk) wrote :

Libvte version
==============
$ dpkg -l | grep libvte-2.91
ii libvte-2.91-0:amd64 0.42.5-1ubuntu1 amd64 Terminal emulator widget for GTK+ 3.0 - runtime files
ii libvte-2.91-common 0.42.5-1ubuntu1 all Terminal emulator widget for GTK+ 3.0 - common files

Running terminator w/o theme colors, then turning them on in preferences
========================================================================
$ ./terminator
Gtk-Message: GtkDialog mapped without a transient parent. This is discouraged.
During terminator reconfigure: #ffffff
During terminal reconfigure: #ffffff
During terminal reconfigure: #ffffff

Running terminator w/ theme colors already on, opening preferences for fun
==========================================================================
$ ./terminator
During terminator reconfigure: #ffffff
During terminal reconfigure: #ffffff
Gtk-Message: GtkDialog mapped without a transient parent. This is discouraged.
During terminator reconfigure: #ffffff
During terminal reconfigure: #ffffff

That is, as they say, damn peculiar!

You're on exactly the same version I am.

I think I may have reproduced though. Are you running this from an installed package from the nightlies PPA? If so I messed up the package because I haven't added the CSS files to be copied. Up until now I was always running direct from a local branch.

I need to tinker around with it till I get it working.

Braden Kelley (redbmk) wrote :

No, sorry! I was running directly from your branch. I didn't actually find
out about the new PPA until you started making noise on this transparency
stuff. I'll have to install that soon - it's looking a lot more stable than
the version I had been using for a while :)

On Mon, Dec 12, 2016 at 11:15 PM Stephen Boddy <email address hidden>
wrote:

> That is, as they say, damn peculiar!
>
> You're on exactly the same version I am.
>
> I think I may have reproduced though. Are you running this from an
> installed package from the nightlies PPA? If so I messed up the package
> because I haven't added the CSS files to be copied. Up until now I was
> always running direct from a local branch.
>
> I need to tinker around with it till I get it working.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1599453
>
> Title:
> transparency does not work in gtk3
>
> Status in Terminator:
> Fix Committed
>
> Bug description:
> Despite the code setting the alpha properly, transparency does not
> work for me in the GTK3 branch.
>
> Changing the transparency setting makes no difference on my terminal,
> running from the tip of the gtk3 branch. It works fine in the GTK2
> version, installed from apt-get.
>
> I'm using Ubuntu GNOME 16.04 with gtk v3.0, libvte v2.91 on a Yoga 3
> Pro. Graphics card is "VGA compatible controller: Intel Corporation
> Broadwell-U Integrated Graphics" with just the standard drivers that
> came with Ubuntu.
>
> I've attached two configs with logs associated with each one:
> 1) the default layout has a single profile, which has transparency
> turned on, titlebar off, and scrollbar turned off.
> 2) the default layout has three profiles displayed.
> 2a) The first is the same as in #1, with transparency turned on.
> 2b) Next to it is a profile with transparency turned off, and with the
> titlebar on and scrollbar on the right.
> 2c) Below both is a profile with transparency turned on higher, with a
> titlebar, and with the scrollbar on the left.
>
> I'm playing around with the code trying to see if I can find a fix
> that will work for me. So far I haven't found anything that doesn't
> break something else.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/terminator/+bug/1599453/+subscriptions
>

OK. The branch you are running from. Are you in the branch base folder and running:
./terminator
or are you using the desktop shortcut you mentioned earlier. Because the fixes to Ambiance rely on being able to load the CSS. And that's how I reproduced the issue, I stopped using the more direct:
./terminator
and used the one on the PATH:
terminator

That's how I saw the same garbage you did :-) If you haven't already, try both and see if there's a difference.

Sorry for the 20 questions, and if I'm being a bit of a thicko. Still figuring this out :-)

Braden Kelley (redbmk) wrote :
Download full text (3.6 KiB)

I'm not really sure what's going on either. I've mostly been running directly from the branch using ./terminator and I keep seeing the white background.

I was planning to take a screencast of the whole thing but it seems to only allow for 30 seconds, which is longer than it takes to download the code on this connection. Anyway, I have the terminal output below of me getting a fresh copy of terminator, installing the patch, then running terminator. I took a screencast of just the part where I opened it so you can see what it looks like.

bmk@namaste ~/code
$ ps -ef | grep term
bmk 21424 1 1 00:39 tty2 00:00:00 /usr/lib/gnome-terminal/gnome-terminal-server
bmk 21870 21565 0 00:39 pts/0 00:00:00 grep --color=auto term

bmk@namaste ~/code
$ bzr branch lp:terminator
Branched 1682 revisions.

bmk@namaste ~/code
$ cd terminator

bmk@namaste ~/code/terminator
$ wget https://launchpadlibrarian.net/297774530/check_vte_colors.diff
--2016-12-13 00:41:04-- https://launchpadlibrarian.net/297774530/check_vte_colors.diff
Resolving launchpadlibrarian.net (launchpadlibrarian.net)... 91.189.89.228, 91.189.89.229
Connecting to launchpadlibrarian.net (launchpadlibrarian.net)|91.189.89.228|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1552 (1.5K) [text/plain]
Saving to: ‘check_vte_colors.diff’

check_vte_colors.diff 100%[===========================================================================================>] 1.52K --.-KB/s in 0.02s

2016-12-13 00:41:05 (78.6 KB/s) - ‘check_vte_colors.diff’ saved [1552/1552]

bmk@namaste ~/code/terminator
$ patch -p0 < check_vte_colors.diff
patching file terminatorlib/terminal.py
patching file terminatorlib/terminator.py

bmk@namaste ~/code/terminator
$ bzr diff
=== modified file 'terminatorlib/terminal.py'
--- terminatorlib/terminal.py 2016-12-11 04:46:02 +0000
+++ terminatorlib/terminal.py 2016-12-12 22:41:12 +0000
@@ -671,6 +671,10 @@
         if self.config['use_theme_colors']:
             self.fgcolor_active = self.vte.get_style_context().get_color(Gtk.StateType.NORMAL) # VERIFY FOR GTK3: do these really take the theme colors?
             self.bgcolor = self.vte.get_style_context().get_background_color(Gtk.StateType.NORMAL)
+ bgcolor = "#{0:02x}{1:02x}{2:02x}".format(int(self.bgcolor.red * 255),
+ int(self.bgcolor.green * 255),
+ int(self.bgcolor.blue * 255))
+ print "During terminal reconfigure: %s" % (bgcolor)
         else:
             self.fgcolor_active = Gdk.RGBA()
             self.fgcolor_active.parse(self.config['foreground_color'])

=== modified file 'terminatorlib/terminator.py'
--- terminatorlib/terminator.py 2016-12-12 11:27:56 +0000
+++ terminatorlib/terminator.py 2016-12-12 22:41:12 +0000
@@ -441,6 +441,7 @@
                 bgcolor = "#{0:02x}{1:02x}{2:02x}".format(int(bgcolor.red * 255),
                                              ...

Read more...

OK, so the latest patch is now putting the CSS files in the correct place when installing the PPA package. And as a result, the installed version looks to be working 100% for me.

Posted before I saw your last message. So yeah, I'm stumped. Everything looks like it should be good. I've tried using the gnome shell, etc, etc. I can't figure it out. Let's see if others have problems, and maybe some more eyes on it will find an answer.

Braden Kelley (redbmk) wrote :

Yeah, I don't actually use that theme or scrollbars, so it won't personally bother me much. But it's pretty strange and I don't know what's going on with it. Maybe the linux distro? I'm using Ubuntu GNOME 16.04, and Adwaita is the default theme, so maybe Unity uses Ambiance by default and sets the default terminal color to something else? I have not idea, but I like the plan of just waiting for another bug report or patch.

Marco A. Rojas (mrcrjs) on 2017-01-14
no longer affects: archlinux
Changed in archlinux:
status: New → Fix Committed
Changed in terminator:
milestone: none → 2.0
rich (richieb-3) wrote :

Any chance of putting up this fix to the debian sid repos are we waiting for 2.0?

@rich: All the changes for this fix were merged into the man branch with rev. 1672 here: http://bazaar.launchpad.net/~gnome-terminator/terminator/gtk3/revision/1672

According to https://packages.debian.org/sid/terminator
You are running 1.90 + bzr revisions up to 1705, so you already have all the latest transparency fixes (provided you are running the unstable terminator package) as far as I can tell.

Also, this is the upstream of Debian; if you want something adding in to the distribution you should really be asking them.

If you are running unstable, but are still seeing issues, you should really raise a new ticket (here in the upstream project is fine) specific to your issue. I got as far as I possibly could with this ticket, fixing everything that was borked on my install.

Oh, and I hope to push 1.91 out in a couple of weeks, 1.92 a month later, then 2.0 the following month. Just hoping people will exercise it and highlight any regressions or critical blockers. See:
https://launchpad.net/terminator/gtk3

rich (richieb-3) wrote :

Thanks for the quick, detailed reply, Stephen.

Apologies about being uninformed regarding the debian repo updating process. Most of my machines are debian unstable, however I just realised I noticed this specifically on kali (which is apparently based on testing, not unstable like I'd thought), so I doubt there is requires another ticket.

Love the software, cheers again.

"I hope to push 1.91 out in a couple of weeks" – Yay! :)

rich (richieb-3) wrote :

Sorry for the extra post, just in case anyone else has my confusion ends up here:

The issue was due to that I was not using a compositor, kali's debian testing-based repos are also fine.

In 3.6.9, (MIGHTY RAVENDARK!!!), transparency worked without a compositor. (Pseudo-transparency, I assume?).

Now, adding `compton --backend glx --paint-on-overlay --glx-no-stencil --vsync opengl-swc --unredir-if-possible` to my startup, everything works well.

Changed in terminator:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers