5 ms·

> or bad text rendering on non-hidpi displays suck, but both have people working on fixing them. It wasn't even acknowledged as a bug in the beginning, even af

• throwaway82652 4y ago
  >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 4y ago
    > 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 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-are-not-telling-you-about-themes/ 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_gtkeddit_a_gtk4libadwaita_reddit/hbk5ty9/#c https://www.reddit.com/r/linux/comments/pg7gkr/introducing_g...
    • throwaway82652 4y ago
      >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#note_740558 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/369 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.