7 ms·

I wish there was a way to make Gnome respect the Xresources colors (even if it's by just generating a theme periodically.) All my Xlib/Xt/tk apps have a nice da

I wish there was a way to make Gnome respect the Xresources colors (even if it's by just generating a theme periodically.) All my Xlib/Xt/tk apps have a nice dark solarized color scheme but the moment I open a GTK app I'm blinded.

smoldesu 5y ago
What I've done is pin my app versions at the last release before GTK4, that seems to do the trick for now (especially since I have yet to encounter a GTK4 app that updated functionality over it's predecessor).
- throwaway82652 5y ago
  Have a look at some of the recoloring support in the new gnome text editor: https://blogs.gnome.org/chergert/2021/12/03/text-editor-happenings/ https://blogs.gnome.org/chergert/2021/12/03/text-editor-happ... Those colorings simply wouldn't be possible without GTK4 and libadwaita. GTK3 has nothing like it.
  - smoldesu 5y ago
    It is/was possible. GTK3 let you edit the CSS of your program to facilitate it. People didn't do that though, because we had a functional theme interface that was much better supported. Well, we did have it at one point... Furthermore, if you consider "changing the way my app looks" to be functionality, then one could argue that GTK4/libadwaita was a functional regression.
    - throwaway82652 5y ago
      You can just look at the screenshots in that blog, GTK4/libadwaita also supports changing the way the app looks. >we had a functional theme interface that was much better supported. Well, we did have it at one point This is revisionist history, GTK3 never had a real theme interface. The changes in libadwaita were directly because CSS is not a functional or reliable way to reskin apps and themes were known as a good way to break GTK3 apps. Using a global CSS has a lot of the same problems as X resources, it's sending a giant string into the app that may or may not override certain things based on random string matching. The CSS styles all cascade together and there is no way to know what app is going to get what styles or enforce that an app uses particular style classes.
      - smoldesu 5y ago
        "Real" theme interface is a moving goalpost. We had stylesheets that could/would be expected to change. Many people decided to switch these stylesheets out, which in turn modified the LAF of their system's applications. The solution to this problem isn't stripping that out and replacing it with a more restrictive UI, the solution was building more robust applications and letting the HIG evolve around it. You know, adapting to the needs of the people who use your software. Unfortunately, the lead GNOME maintainers never asked for the community opinion, so we ended up with... whatever the hell Libadwaita is. In any case, I've ended up migrating away from GTK4 for the majority of my use cases anyways. Like I said, it has given us no functional changes in any of the apps I've used (or seen, for that matter), so I don't really feel bad dropping it from my systems. It also doesn't make me feel bad freezing all the apps I write at GTK3, since the developer experience is frankly so much better the further you go back in GTK history.
        throwaway82652 5y ago
        >the solution was building more robust applications and letting the HIG evolve around it. This is literally exactly what is happening in libadwaita. The stylesheets are still there but the apps are more robust by enforcing the use of particular styles. I don't know what else you would expect here. In this situation "more robust" is always going to mean restricting the theme options to a subset which we know works. >Unfortunately, the lead GNOME maintainers never asked for the community opinion This is a nonsensical statement and is a misunderstanding of how open source works. Decisions are not made based on "community opinions" they're made by those who show up and do the work. It would make no sense for any open source maintainer to ask for "community opinions". Of course if you ask random commenters on Hacker News and Slashdot if they want you to develop all kinds of impossible features and give it to them for free, they will always say yes. >Like I said, it has given us no functional changes in any of the apps Again please check those screenshots in the blog. The recoloring functionality there would not be possible in GTK3. It's not very fun to talk to you when you repeatedly ignore what I'm saying.
        smoldesu 5y ago
throwaway82652 5y ago
Libadwaita may actually be an improvement there if they ever finish the recoloring API, then you will actually have a chance to apply arbitrary colors to an app, without screwing up the contrast. But I'm more puzzled as to why you're using xlib and xt apps in 2022.
- exfascist 5y ago
  I wasn't aware xlib and xt had an expiration date.
  - throwaway82652 5y ago
    In my experiences, apps using those toolkits usually have a lot worse usability issues than not being able to change the colors.
    - anthk 5y ago
      I have XAW3D preloaded with LD_PRELOAD for all Athena software I use. Much better than plain XT.
    - exfascist 5y ago
      Interesting, in my experience GTK3+ apps have worse usability issues (especially on touch screen devices.) EDIT: I can't reply to your comment so I'll write the reply here. Yes, on paper GTK3+ sounds like it would be more touch device friendly. They make up for it with absolutely awful, huge, modal UIs with low information density (missing scroll gestures with Xinput2 don't matter if you're not having to scroll all the time.)
      - throwaway82652 5y ago
        I don't understand this reply at all. Xt has no support whatsoever for touch devices or gestures. GTK3/4 actually has proper support for most of the XInput2 features.
      - throwaway82652 5y ago

smoldesu 5y ago

What I've done is pin my app versions at the last release before GTK4, that seems to do the trick for now (especially since I have yet to encounter a GTK4 app that updated functionality over it's predecessor).

throwaway82652 5y ago
Have a look at some of the recoloring support in the new gnome text editor: https://blogs.gnome.org/chergert/2021/12/03/text-editor-happenings/ https://blogs.gnome.org/chergert/2021/12/03/text-editor-happ... Those colorings simply wouldn't be possible without GTK4 and libadwaita. GTK3 has nothing like it.
- smoldesu 5y ago
  It is/was possible. GTK3 let you edit the CSS of your program to facilitate it. People didn't do that though, because we had a functional theme interface that was much better supported. Well, we did have it at one point... Furthermore, if you consider "changing the way my app looks" to be functionality, then one could argue that GTK4/libadwaita was a functional regression.
  - throwaway82652 5y ago
    You can just look at the screenshots in that blog, GTK4/libadwaita also supports changing the way the app looks. >we had a functional theme interface that was much better supported. Well, we did have it at one point This is revisionist history, GTK3 never had a real theme interface. The changes in libadwaita were directly because CSS is not a functional or reliable way to reskin apps and themes were known as a good way to break GTK3 apps. Using a global CSS has a lot of the same problems as X resources, it's sending a giant string into the app that may or may not override certain things based on random string matching. The CSS styles all cascade together and there is no way to know what app is going to get what styles or enforce that an app uses particular style classes.
    - smoldesu 5y ago
      "Real" theme interface is a moving goalpost. We had stylesheets that could/would be expected to change. Many people decided to switch these stylesheets out, which in turn modified the LAF of their system's applications. The solution to this problem isn't stripping that out and replacing it with a more restrictive UI, the solution was building more robust applications and letting the HIG evolve around it. You know, adapting to the needs of the people who use your software. Unfortunately, the lead GNOME maintainers never asked for the community opinion, so we ended up with... whatever the hell Libadwaita is. In any case, I've ended up migrating away from GTK4 for the majority of my use cases anyways. Like I said, it has given us no functional changes in any of the apps I've used (or seen, for that matter), so I don't really feel bad dropping it from my systems. It also doesn't make me feel bad freezing all the apps I write at GTK3, since the developer experience is frankly so much better the further you go back in GTK history.
      - throwaway82652 5y ago
        >the solution was building more robust applications and letting the HIG evolve around it. This is literally exactly what is happening in libadwaita. The stylesheets are still there but the apps are more robust by enforcing the use of particular styles. I don't know what else you would expect here. In this situation "more robust" is always going to mean restricting the theme options to a subset which we know works. >Unfortunately, the lead GNOME maintainers never asked for the community opinion This is a nonsensical statement and is a misunderstanding of how open source works. Decisions are not made based on "community opinions" they're made by those who show up and do the work. It would make no sense for any open source maintainer to ask for "community opinions". Of course if you ask random commenters on Hacker News and Slashdot if they want you to develop all kinds of impossible features and give it to them for free, they will always say yes. >Like I said, it has given us no functional changes in any of the apps Again please check those screenshots in the blog. The recoloring functionality there would not be possible in GTK3. It's not very fun to talk to you when you repeatedly ignore what I'm saying.
        smoldesu 5y ago

throwaway82652 5y ago

Libadwaita may actually be an improvement there if they ever finish the recoloring API, then you will actually have a chance to apply arbitrary colors to an app, without screwing up the contrast. But I'm more puzzled as to why you're using xlib and xt apps in 2022.

exfascist 5y ago
I wasn't aware xlib and xt had an expiration date.
- throwaway82652 5y ago
  In my experiences, apps using those toolkits usually have a lot worse usability issues than not being able to change the colors.
  - anthk 5y ago
    I have XAW3D preloaded with LD_PRELOAD for all Athena software I use. Much better than plain XT.
  - exfascist 5y ago
    Interesting, in my experience GTK3+ apps have worse usability issues (especially on touch screen devices.) EDIT: I can't reply to your comment so I'll write the reply here. Yes, on paper GTK3+ sounds like it would be more touch device friendly. They make up for it with absolutely awful, huge, modal UIs with low information density (missing scroll gestures with Xinput2 don't matter if you're not having to scroll all the time.)
    - throwaway82652 5y ago
      I don't understand this reply at all. Xt has no support whatsoever for touch devices or gestures. GTK3/4 actually has proper support for most of the XInput2 features.
    - throwaway82652 5y ago