Skip to content

preGTK4: Stop using StyleContext bg, border colors

Daniel Boles requested to merge dboles/inkscape:djb_preGTK4_theme_colors into master

Opening mostly for testing. I think everything here looks fine, and I tested everything I know how to get to - but obviously want more eyes/hands on it before merging.

This is basically a 'lightest touch' way to get us ready for GTK4, while using the same logic in GTK3, which I think would be good to get developer and user eyes/hands on quite early, to catch any quirks/nuances it might cause (hopefully not, but y'know how it goes) - rather than only doing it at the point of migration and ending up having to scramble later.


Stop using StyleContext.get for bg & border colors

GTK4 will not let us do that, as it REMOVES gtk_style_context_get(). So,
better rip the band-aid off early and see how it goes… if this creates
[m]any ensuing problems, we get more time to figure out their solutions.

So, now, where other colours are needed, 'stash' it in fg color, via the
already-used technique of adding a CSS class during draw, then querying
the 'normal' / 'foreground' CSS color. This was advised against by 2 GTK
maintainers in IRC when I mentioned it, & they don't even think it would
work - despite GtkCalendar in GTK+3 doing just that... Well it DOES, and
we were already relying on doing so, so… if it breaks later, let's deal
with it then. We don't have infinite time to cater to GTK's every whim…

So this adds get_color_with_class() in ui/utils, taking a non-const SC.

Also, everywhere, I stop using StyleContext->get_color() directly, but
instead go via said file's get_foreground_colour(StyleContext), as that
makes us more ready for GTK4 (where we will just need to pass the Widget
instead): it always uses the current state flags, which is all GTK4 will
allow, since it doesn't let us pass custom flags to get_color() anymore.
That may mean we need to un-backdrop windows before querying? We'll see!
Edited by Daniel Boles

Merge request reports