@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.
@ebassi sorry for my English and sorry if I'm a bit annoyed but I spent hours to read documentation about GTK 4 to finally realize that I will not be able to continue my idea...
@metal3d I understand the annoyance, but really: what you want to achieve was never supported in 20+ years, and it's not really supportable programmatically.
At most, you can emulate the appearances of libadwaita by looking at the generated CSS, and by using the documentation; for anything else, you'll have to use the good old Eyeball Mk 1, or the GTK inspector, and then emulate the result.
@ebassi the goal is to be able, from fyne app (in go) to get information about the current gnome theme colors. Not to get the Css file or attributes with inspector to create the theme by hand.
@ebassi as the fyne app is absolutely cross platform (even with android) and statically compiled, I need a way, even by command line, to get at least the 2 majors colors. GJS was enough (with get_context().get_background_color()) with a fake window. That was really enough even if it's not very efficient.
@metal3d at most you can use get_context().lookup_color("window_bg_color"), but that requires libadwaita.
Same if you want the light/dark information: you need libadwaita or libhandy, or you need to watch the system setting yourself—GTK by itself does not have a light/dark default theme.
@ebassi if the window element declares a "color" so I want to get it, either I've got an empty string and that's not a problem. I only need to get it, empty or not
@ebassi That's why get_style_context() was cool, I don't mind if the theme doesn't give a color, I just want to check it
@metal3d Again: there is no color. For instance, what's the color of this background? And if you think: "that's a special case", the background of a window can be a combination of gradients, or a repeating texture, in any theme. The only way to give you this information would literally be to expose the CSS state as public API, which is, sadly, entirely unsustainable. We're not Google, Microsoft, or Apple.