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
>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.
> 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.
I didn't say that it was a problem with GTK. I said that it's a problem in the dark version of the Adwaita theme. I disagree with the choice of the background and the foreground color.
> Theming is only a band-aid
It's the only solution that comes to mind, unless there's a One True Theme out there that works for everyone.
> I suggest at minimum turning the contrast down on your display or permanently enabling night shift mode.
I've already enabled night mode which reduces the gamma of the display. Turning down the contrast of the monitor doesn't sound right because there are low contrast, medium contrast, and high contrast themes out there. Fortunately, there are objective criteria to measure the contrast. When using gedit, for example, with the Adwaita dark theme, I got `#EEEEEC` as the foreground color of text and `#303030` as the background color which gives a contrast ratio of 11.36 according to the WCAG 2.0.
In my anecdotal experience, contrast ratios above 7 or 8 when using dark mode often end up causing halation which makes GTK apps unusable or uncomfortable for me for more than a few minutes.
Of course, some people may not have this problem and they might find these choice of colors as perfectly normal which is exactly why theming and user choice is important but it seems to be heavily de-emphasized in the GNOME world and the focus is on finding "perfect" solutions.
> Another option may be to pursue something like a gnome extension
unsupported, generally looked down upon, and called as hacks by the GNOME team, just like GNOME tweak tool and GTK_THEME
> No, the current draft allows changing all colors
Does it allow changing the background color of a window and foreground color of the text in a GTK app and would it be officially supported?
>I said that it's a problem in the dark version of the Adwaita theme.
I don't understand what this has to do with Adwaita either, as I said this can affect every toolkit and every app and every web site because most of them have their own theme. For example this site we're on now has an IMO awful default theme that strains my eyes, and doesn't have any official support for theming. We can't blame GNOME for that one.
>It's the only solution that comes to mind
Actually I mentioned a few other solutions that could work. Theming is not even a real solution sometimes, for example some closed source apps just don't support theming at all and can't be easily hacked to change the colors. If that happens you're pretty screwed, unless you pursue an alternate solution.
If the other GNOME apps decide to support these type of themes it will be a while before that happens too because their ports to GTK4 and libadwaita are not finished, and because they will probably wait for the recoloring API instead of doing it all in CSS like the text editor currently does.
>Of course, some people may not have this problem and they might find these choice of colors as perfectly normal which is exactly why theming and user choice is important
But this isn't an argument in favor of "theming and user choice", this is an argument in favor of providing a low-contrast option for accessibility.
>unsupported, generally looked down upon
This is incorrect. There are several official extensions maintained by GNOME developers.
>and called as hacks by the GNOME team, just like GNOME tweak tool and GTK_THEME
That's somewhat true, extensions can be very hacky. It is however a lot easier to maintain one extension then it is to maintain thousands of themes for every possible toolkit, app, web site. If you view theming as the only other solution then your choice is really with choosing one hack versus another hack. If you're not planning to develop any themes or extensions and maintain them yourself indefinitely then I really don't understand why you would even care about themes at all, the best option for you would be a low-contrast toggle.
I think you may be confused about the full definition of "unsupported" here. The tweak tool and GTK_THEME (and in some sense, extensions) are not considered unsupported because nobody wants those features. The missing piece is for somebody to figure out what a reliable solution is and make everything work correctly with a real API, and then volunteer to support that for years.
>Does it allow changing the background color of a window and foreground color of the text in a GTK app
In some way it does. I don't know why you're asking me this because I can't decide for you, if you're an app or theme developer you need to look at the draft yourself to see if it would be adequate for you. From what I hear, it should roughly do what you can see in those text editor screenshots I linked above.
>would it be officially supported?
I don't know what the status of it is, I only saw the draft. You would have to ask the developers. IRC or Matrix is a good place to ask questions.
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.