[throwaway82652]

>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 it, just to make a point and attack them, please stop doing that. I'm like you and I just want the bug to be fixed, these kinds of bad faith comments calling people "dense" aren't helping. This is trying to paint someone as being stubborn here after they already changed their mind and did what you want. Just take the victory, you don't have to be a sore winner.

>Sure, but in that case, an officially supported method to change the theme should be provided in case I don't agree with your choice. Apparently, GNOME tweak tool was never supported, is not supported, and will never be supported. For now, GTK_THEME is being presented as an alternative but do you expect me to close all of my programs and relogin to my session to change my theme? Should I create wrapper shell scripts for all of my GTK apps?

GTK_THEME is mainly a setting for developers, you should probably not be using that unless you're developing a theme to be upstreamed with an app. It has all the same issues as the tweak tool where it's unreliable and some apps may not function correctly with some themes or may not respect the setting at all.

If you're interested to actually help, what you should do is contribute towards fixing issues with the upstream theme. In almost every case when I've seen people complain about the default theme it's because of fixable bugs in the theme that upstream wants fixed. And if you want to do more, you can contribute towards the libadwaita theming API which is intended to be a real theming API and not a hack like GTK_THEME or the tweak tool. It's still being designed so now would be the time to start contributing if you want to get in early.

>The fact that there are no non-trivial GTK4 apps out there that don't use libadwaita or libgranite tells me what I need to know.

That those libraries have widgets and skins that developers really like and want to use? I'm sorry I just don't see what you're getting at here. Do you expect GTK to try to please everyone by merging all the widgets from libadwaita and libgranite and deprecating those libraries? Because I think that would be a lot worse.

>Even LibreOffice uses libadwaita now.

Actually it doesn't, that was just a proof of concept. But even if they did, it would be entirely optional.

[_2paq]

> 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, this is new information because this blog post

https://blogs.gnome.org/alatiera/2021/09/18/the-truth-they-a...

and everyone else I've talked to seems to be presenting GTK_THEME as one of the options for changing themes for GTK4 apps, which is absurd user experience, to say the least.

> It has all the same issues as the tweak tool where it's unreliable and some apps may not function correctly with some themes or may not respect the setting at all.

Now I'm wondering if this information was intentionally withheld in that blog post.

> In almost every case when I've seen people complain about the default theme it's because of fixable bugs in the theme that upstream wants fixed.

What if I disagree with basic choices like the dark mode background color? The contrast between the background and text in dark mode is too high for me and I get halation in my eyes within a few minutes of reading text inside a GTK app with the dark version of the Adwaita theme.

I'm fairly certain that this issue won't be entertained on their issue tracker and even if it was, I'm not sure I want to subject myself to their behaviour as shown in the link above and the font issue in context.

> a real theming API

that "real" theming API just changes accent colors and wouldn't solve my issue

> Do you expect GTK to try to please everyone by merging all the widgets from libadwaita and libgranite and deprecating those libraries?

If there are no feasible alternatives to develop GTK4 only apps besides creating your own widgets from scratch, the practical outcome would be that most independent developers would end up choosing libadwaita not because they want their apps to be GNOME apps but because it would be relatively harder to not use libadwaita. This can be seen in this comment from the developer of GTKeddit.

https://www.reddit.com/r/linux/comments/pg7gkr/introducing_g...

[throwaway82652]

>the Inter font issue comes to mind

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.

[_2paq]

> 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.

https://coolors.co/contrast-checker/eeeeec-303030

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?

[throwaway82652]

>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.

>When using gedit

Just FYI gedit is replaced in GNOME 42 with a new GTK4 text editor that has themes built in: https://blogs.gnome.org/chergert/2021/12/03/text-editor-happ...

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.