Comment 2 for bug 1745825

Given the existence of this cmdline option, the approach the transparency patch takes here (locating a terminal window) is broken by design.

One possibility would be to no longer rely on the transient parent (and not set that property either), but instead figure out the value of background-darkness without having access to a terminal window.

The last time I looked at GTK+'s API, it seemed pretty easy to build up an imaginary node with imaginary widgets of certain CSS classes/names along its path, and query its style. I've never done it, though.

Another, probably simpler and cleaner solution would be to redesign the Preferences UI not to require knowing this value.

Gnome-terminal's Preferences UI had several changes throughout the years, and they went in the direction of simplification, and squeezing into a simple line the features that really don't require two lines. E.g. it used to have

  [x] Use the system fixed with font
  Font: [Monospace 9]

and now it has

  [x] Custom font: [Monospace 9]

Transparency also occupies two lines:

  [x] Use transparent background: none --o----- full
  [x] Use transparency from system theme

The second one is only shown if the system theme defines a level of transparency, as for example Ubuntu's default Ambiance does, while GTK+'s default Adwaita doesn't. Detecting this is what causes the crash, so would be nice not to require knowing. (On a side note, the first option is insensitive if the second one is checked, which means the two lines should really be swapped.)

My recommendation, in the spirit of Font's simplification on the UI:

  [x] Custom transparency: none --o----- full

When unchecked, the transparency defined by the theme would be used (which may be translucent, or may be fully opaque). When checked, the slider becomes sensitive and its setting is used instead of the theme's. There's no need for an explicit checkbox to disable/enable transparency, disabling it can simply be achieved by sliding the slider all the way to the left.

This would also require reducing the number of dconf options from 3 to 2, which is again IMHO a nice simplification (although ideally a one-shot migration should be performed).