@metal3d the default GTK4 theme does not provide any source of stability for the colors, mostly because it never did, not even in GTK2 or GTK3; libadwaita, on the other hand, does: https://gnome.pages.gitlab.gnome.org/libadwaita/doc/1-latest/named-colors.html
@metal3d but if you want to *draw* with CSS colors, then you need to use the gtk_render_* API in GTK3, and the GtkSnapshot API in GTK4. That has been the case since GTK 3.0. The old "ask the style machinery for a color" made sense in GTK2, where you only had colors. With the introduction of CSS, you can have gradients, textures, blended layers, or (most likely) a transparent value. There is no "color" to be queried in many cases.
@metal3d It's not a case of being "better" or "worse" (though CSS allows us to do better rendering without loading shared modules that literally put pixels inside widgets, like GTK2 engines did); it's a case of being an entirely different API.
@ebassi that's not to draw on GTK. That's to get the theme generic colors (background and foreground) to color an app using another library (fyne.io).
There is no dark/light information on gnome and nothing to get the theme base colors.
Actually I call some gjs command to get a invisible one shot window color from get_context() method. Grk4 abandoned this.
@ebassi that's something that I don't understand... OK, css is cool to make whatever we want for themes. But there are at least 2 needed information, the "dakmrk/light" switch and "foreground/background" colors. That's anormal to have to call GJS (or python) from another language/lib to find this. And anormal that now it's impossible to get these information.