The “don’t theme my app” thing just tells me that GNOME/GTK+/Adwaita aren’t built in a way that gracefully handles theming, or that devs building apps with them are doing things like hard coding colors when they should be using dynamic system colors such as those provided by UIColor[0] in UIKit.
Supporting themes imposes an ongoing technical burden across the whole ecosystem. It's not worth it. You don't hear people say "I hate macs because I can't make my title bars purple".
Yep and that’s great, but there are still other legitimate uses for theming. One of mine is cutting down padding to reasonable levels — GNOME is much more usable to me when using a theme like Nordic or Skeuos, both of which do that.
This attitude is why we can no longer have stuff that doesn't only come in "light theme" or "dark theme". I consider this a regression. Let me theme my damn computer the way I want. It's called a Personal computer for a reason.
It is silly that dark mode isn't regarded the same as just switching themes. Forcing its adoption however breaks dependency on non-themable components so its popularity is still a net benefit.
There's a difference between "we'll test and support two color schemes" and "we'll design ui with parametrised colors, shapes and text sizes which can adjust to any change and still be usable". If we settle on bright/dark/colorblind mode selectors that everyone expects to be supported, I'm happy. I've seen themes in the past and there was always a few apps which just can't resize elements in the expected way, or the backgrounds don't tile correctly, or ...
Ok, then don't support it. But don't patronise me. Don't tell me I couldn't possibly wield the power of recolouring a piece of UI without hurting myself, and deny me the chance to even try.
But libadwaita hasn't taken away the ability to try? You can still load custom themes through GTK_THEME and specific CSS through ~/.config/gtk-4.0/gtk.css.
Don't get me wrong, I'm glad to have any measure of control at all. It's just that I'm frustrated that we had infinitely more capable theming system already in place, and it was broken.
I want customizable color schemes and fonts and sizes. It's nice as a user to pick full-on custom themes. Sadly even though Qt is based around theming, I had to turn off theming for semi-customized controls (colored sliders) to make them render correctly on Windows and Linux Breeze/Fusion. And it's more work to verify my app looks good across OSes when QButtonBar and QFormLayout change appearance on different OSes. So finding a good solution is nontrivial.
I'm quite sure you could change system colors willy nilly in OS 8. It was great fun. I miss that part - the feeling of having "your own" system.
Since customization where pretty standard back then, it feels like product managers pushing their "vision" rather than technical difficulties preventing that nowadays.
Kaleidoscope and later on Appearance Manager in Classic Mac OS were so much fun. No OS theming system I’ve encountered since have been as capable as those were.
Ye I wonder what fantastic APIs were actually exposed. I remember some 3rd party screen saver I had. Where like Goofy peeked out of folders and Donald Duck was cleaning up some file mess. I mean, how could you even program that?
I think it was on the real desktop, not some bitmap, but not too sure.
I get what you’re saying but I find GNOME more evocative of iPadOS than macOS. It’s almost exactly what you would get if you tried to create a desktop environment using an iPad as a starting point.
macOS still has several traditional desktop affordances that are eschewed by GNOME, like full menus (not just hamburger junk drawer menus) and customizable toolbars.
I do say that. The light-grey on top of light-grey theme means a lot of times the only way to tell which is the foreground window is by looking for the 3 colored dots.
I feel like partially the movement happened because some themes made the apps unusable and then instead of blaming the theming, users blamed thee app developers instead.
In some cases badly designed themes (like dark gray labels on black backgrounds) are the culprit, but most often it’s a result of the app developers hard coding colors in their UI elements assuming all users will be using a similar theme.
That’s not only bad for custom theme users, it’s bad for accessibility since there’s no way for increased contrast modes to modify the hard coded colors. Apps really just shouldn’t hard code colors.
KDE (or rather Qt) goes even further and still let's you completely change the way interface elements are rendered, which is great because it means you can use the same look across versions if you want to and are not beholden to the latest design fad.
I build bespoke UI elements for iOS apps all the time and building them in such a way that they look and function correctly not only across light/dark and accessibility modes but also future OS versions is not that difficult, and with how they’re built I don’t see them breaking even if iOS took on a radically different appearance. They might not match perfectly but usability will not be impacted.
If this is not reasonably possible with GTK, then it seems pretty clearly like a weakness of how GTK handles themes. Personally, I believe that CSS is ill-suited for the task and is responsible for many of the issues depicted in that blog post.
> not only across light/dark and accessibility modes but also future OS versions
When Apple makes a future OS versions they are expected to avoid breaking apps.
The comparison here would be not to future iOS versions, but to arbitrary jailbreak tweaks that overhaul the look system-wide. You're not ensuring that will look good with your app ;)
[0]: https://developer.apple.com/documentation/uikit/uicolor/ui_e...