Comment 10 for bug 1599453

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.