Hacker News Reader

Comment by kitsunesoba | Hacker News Reader

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.

[0]: https://developer.apple.com/documentation/uikit/uicolor/ui_e...

View on HN

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

You do however see many complaints when an app doesn’t support dark mode (which is closer to the typical use case of themes).

Additionally, see my other comment about accessibility, which is also negatively impacted by hardcoded UI appearances.

Dark Mode is first class in the next releases of GTK4 and LibAdwaita. It'll be available in GNOME 42 and Fedora 36.

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.

Or putting the scroll bar back, or getting rid of the awful client side decorations.

I switched from Mac to Linux (in 2008-2009) because I could understand it and make it my own, among other things with theming.

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

If not for scrollbars color, I certainly dislike the macOS GUI for its straightjacket approach. (Also, poor window management.)

I wish Gnome folks did not keep on copying it more and more. I see why it's easier to do, but KDE somehow manages.

(And if one thinks that Apple UX design can't go wrong, remember Macbooks from a couple of years ago.)

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.

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.

No one can deny you anything with FOSS. Go ahead, edit everything, just please don't complain to the developers that something broke because of that.

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.

MacOS at least lets users choose the accent color: https://osxdaily.com/2020/07/24/change-accent-color-mac/

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.

Agreed, definitely. OS should provide basic colorsheets that the apps use, and those sheets should be freely modifiable.

Which is why I really like KDE.

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.

- Gnome includes high contrast and dark modes and encourages app developers to test against them.

- Requiring apps not to use custom colors alone won’t fix it. Any bespoke UI element an app includes is at risk of breakage when a custom theme redefines the entire world. https://blogs.gnome.org/tbernard/2018/10/15/restyling-apps-a...

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 ;)

This is exactly the reason.

But people seem to deliberately obscure why the Gnome devs are doing this and instead accuse them of being lazy and/or dictators etc.

Removing themes because they have in some rare cases caused problems is a pretty lazy response.

Reply on news.ycombinator.com