Earlier quoted context omitted.
>It wasn't even acknowledged as a bug in the beginning, even after screenshots with clear signs of regression were posted. Matthias Clasen closed the bug report saying it wasn't a bug but an intended feature. There's really no appropriate words to describe such behaviour Please stop fanning this flame war. You're making it worse and choosing to omit that the bug was reopened after a better argument was made in favor…
> This is trying to paint someone as being stubborn here after they already changed their mind I just pointed it out because as I said, this behaviour is fairly common on the GNOME issue tracker. There are numerous instances but for now, the Inter font issue comes to mind https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2331 > GTK_THEME is mainly a setting for developers, you should probably not be using that Well…
I don't see anything objectionable there. Pay particular attention to this response: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2331#not...
Sadly it's not possible to design a GUI that has correct spacing and stays consistent with every font choice. Variable-width fonts don't function like that, widgets sized to a piece of text will have their layout interfered with when the font size changes.
>this is new information because this blog post... Now I'm wondering if this information was intentionally withheld in that blog post.
It wasn't withheld and it's not new information. You're still assuming bad faith and you need to stop this. Notice the part where it says "Compared to GTK 3", if you're familiar with theming GTK3 you should be well aware of the limitations with those themes. Not much has changed there at all. Theming in this way is essentially just hacking the hardcoded colors to be different.
>The contrast between the background and text in dark mode is too high for me
I have the same problem with some apps and I want you to find a solution but I don't understand what this has to do with GTK. That is going to be a general problem with lots of programs or websites that you visit and reskinning each of them is a huge pain and is not guaranteed to work. Doubly so if you use apps that have any other toolkits or use a custom toolkit, the contrast will still be inconsistent. I speak from experience here. Theming is only a band-aid, I suggest at minimum turning the contrast down on your display or permanently enabling night shift mode. That may not make the contrast perfect but it would at least ensure you never see any high contrast text in any app.
Another option may be to pursue something like a gnome extension that dynamically adjusts the screen's gamma and contrast based on the dynamic range calculated from the contents of the windows. That should be a lot more useful and flexible than manually reskinning every app you use. And it works in other situations like for example, if you have two apps side by side and one has a brighter background color than the other, it would notice that's happening and dynamically adjust accordingly so you don't strain your eyes when moving from one app to the other. I think it's misplaced to present this as a theming problem when this sounds like a general usability problem.
If you really do think it's a theming problem then maybe you could campaign for an officially supported low-contrast option, but that would be far away because every toolkit would have to implement it, and old apps will probably not be updated to support it, and it still probably won't work on arbitrary web sites. From a libadwaita perspective the recoloring API may do everything that you need, in my experience it's web sites that are the worst offender when it comes to eye-straining themes.
>I'm fairly certain that this issue won't be entertained
This doesn't make any sense. Both of those issues you linked did get entertained, and the maintainer was still open to patches to fix the font issue.
>that "real" theming API just changes accent colors and wouldn't solve my issue
No, the current draft allows changing all colors: https://gitlab.gnome.org/GNOME/libadwaita/-/merge_requests/3...
>If there are no feasible alternatives to develop GTK4 only apps besides creating your own widgets from scratch
This is the same as it was in GTK3. It hasn't changed at all, the only difference is the library is called libadwaita instead of libhandy. You also don't have to recreate widgets from scratch, that developer appears to be confused. It's certainly possible for an app developer to reskin the libadwaita widgets. But of course, just as in GTK3 they would have to put in the work to write and maintain their own skin, and ship that as part of their app. Or they can just wait for the recoloring API.