jnsh / arc-theme

A flat theme with transparent elements (actively maintained fork)
GNU General Public License v3.0
902 stars 77 forks source link

arc-theme: does not define @text_view_bg named colour #80

Closed fossfreedom closed 3 years ago

fossfreedom commented 3 years ago

Details

Raised on behalf of Debian bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=970988

GTK 3.24.22 introduced a new named colour, @text_view_bg, which the vte terminal library has started to rely on, causing misrendering in themes that do not define it (see https://gitlab.gnome.org/GNOME/vte/-/issues/284). Other text-heavy applications might also start to rely on that named colour in future, particularly if they have a dark mode.

Please add @text_view_bg to this theme so it will not cause misrendering in future.

The new colour is intended to be used as a background for text views, contrasting well with @theme_text_color. For example, gnome-terminal and other vte applications draw text in @theme_text_color on a background of @text_view_bg.

The reference implementation is that in the light variant of GTK's default Adwaita theme, @text_view_bg is the same white as @theme_base_color and @content_view_bg, but in the dark variant of Adwaita, it's a darker grey than @theme_base_color and @content_view_bg, to give white text better contrast.

If this theme does not need to distinguish between text views and other application content areas, defining @text_view_bg to be the same as @theme_base_color or @content_view_bg would be appropriate.

Notes: The Debian maintainer has committed a workaround upstream in the 0.62.x branch, which will be in Debian soon; but vte upstream asked not to commit that change to master, so the workaround will be going away in the next release cycle of vte.

jnsh commented 3 years ago

Thank you for the report. The @text_view_bg public color was added in https://github.com/jnsh/arc-theme/commit/2c726e439b1f157f9a2f54955e51a8c9900ff41a.

I've opted to use the same color from @content_view_bg, which means this shouldn't result in any visual changes for now. I may later adjust the color to be darker on the dark variant, based on the upstream discussion, but this needs some more though on whether this is good enough reason to change the existing design, and what the new color should be to stay consistent with the design.

My plan is to roll out a new release with this fix after all possibly remaining GNOME 3.38 regressions are sorted out, but it may take some time until the full GNOME stack is updated in Arch Linux and I can test everything properly.

Since the release may still be a few weeks away, I'd suggest package maintainers to consider cherry-picking the above commit to fix the issue with vte3-0.62.0, unless this is already worked around in the vte3 package itself. (@NicoHood, this would be nice for the Arch package.)