@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.
@metal3d It was already impossible to support in GTK3, the old "give me a color" API was mostly an early migration API for applications porting from GTK2.
If you want the light/dark theme colors, then you want libadwaita's named colors from the documentation, no need to use any API.