[OsrsNeedsf2P]

Sometimes I wonder why there isn't more enthusiasm around theming. Chicago95[0] is popular, but I also love how Garuda[0] themes KDE. There's some small websites for downloading themes on various DEs, but most of them are a bit jank and it seems built-in support beyond basic things like accents aren't there.

[0] https://github.com/grassmunk/Chicago95 [1] https://garudalinux.org/editions (screenshots don't do it justice)

[WD-42]

The Gnome/gtk folks have been systematically removing theming capabilities for the last decade+ in the pursuit of an Apple-like philosophy towards ui. This has really killed a lot of theming because so many apps use GTK.

[cosmic_cheese]

Even before that, GTK app theming was a bit hit or miss, likely because of the way GTK uses CSS for themes.

Personally I believe CSS to be quite ill-suited for the purpose. It’s ok if you’re writing a theme for a bespoke one-off app but breaks down in the system theme use case. In particular, CSS inheritance makes for a lot of unnecessary trouble for both third-party themes and accessibility affordances.

Last I knew there was something of a disinclination away from paramaterization in the GTK dev sphere too, which is another significant problem for third party themes and accessibility. Hardcoded fonts, colors, etc makes for pointless brittle rigidity.

[ChocolateGod]

GTKs CSS engine is great for app developers because it's powerful and easy. You can make something look slick with little work.

But its terrible for themers, it's like running a CSS override on every site that runs Bootstrap and expecting it to work properly. It won't.

I don't run any themes anymore so it doesn't bother me.

[WD-42]

Before css there were engines, which were like families of themes. One of them was the pixmap engine which was what it sounds like: it used images to make up elements of the theme. Some of the most ambitious themes used this engine. CSS didn’t come until much later.

[cosmic_cheese]

Yeah I recall having to install engines for some themes. One of them was murrine I think?

[gnomeluvscorpo]

Perhaps with all these changes to GUI since initial Shell release their goal is to enter some niche mobile market and call job done. Because nothing else explains all this interface gutting out they did over 14 years.

Once they finish sucking donations and other forms of financial support they'll probably announce it's time to "sunset" Gnome/gtk because it sadly didn't met unspecified expectations of unspecified group of people.

Gnome team, what they did and what they still want to do, their attitude towards users - especially those who dare to criticize them is THE result of polluting FOSS with corporate style of software development.

Theming and customization of Linux is half-dead because of what happens at Gnome.

[Mountain_Skies]

Chasing after The Year of Linux on the Desktop is the community's great white whale. The thinking seems to be that if Linux can be made to look enough like the major mainstream OSes, the masses will flood into Linux and the people who lead them there will get to be the heroes of the day. Problem is the mainstream OSes make UI decisions for many reasons, and the end user often isn't the main concern. Linux could, and in the past did, make itself the OS of user empowerment and choice instead of being a watered down version of whatever is in fashion with the PMs at Microsoft, Apple, and Google.

[aecsocket]

This opinion of "Gnome is killing customization" is something I see quite a lot, but which I think people take the wrong way. It's absolutely true that Gnome is designed to be less themeable than other DEs like KDE, or individual WMs - and by extension, GTK apps and apps designed to be used on Gnome are harder to customize/break more when you do theme them. But I disagree that "customization of Linux [being] half-dead" is a bad thing; on the contrary, I support the lack of theming options, and I like that there's someone on the Linux desktop that pushes this hard for consistency.

To make my biases clear: I'm a software developer that uses Gnome daily, and is developing a GTK/Adwaita app. I used to rice a lot back in the i3 days, but I don't particularly care about that nowadays, and stick to the defaults when I can. For my purposes, GNOME and Adwaita is perfect since it's very opinionated by default, and you can make good looking apps with minimal effort. Since all Adwaita apps are supposed to look similar and follow the same HIG, most of my desktop apps have the same look - but more importantly, the developers of the apps can also be confident that their apps look correct on my desktop. This is something that developers in the GTK space generally want, and for good reason[0].

One argument is that you as a user of the desktop should be able to have the final say on how your apps look, which is a totally valid take! And there are DEs, WMs, and apps which give you this freedom like Hyprland. But this doesn't guarantee that those apps will look good, or look consistent with each other, or even act consistently across apps. On the other hand, I as an app developer want to guarantee that my app looks good on your desktop, and the easiest way to achieve that is to target a single desktop environment, rather than an infinite combination of possibly-similar-but-maybe-completely-different desktops. Every preference has a cost[1][2], and when you take this philosophy beyond just preferences and expand it to color schemes, padding, margin, iconography, typography, it becomes unmanageable.

This isn't to say that GNOME is perfect, and I disagree with the project on some fundamental technical things like not supporting xdg-layer-shell[3], and refusing to accommodate server-side decorations for apps which don't want to render decorations themselves. (On the cultural side I can't comment, since I have no experience with that.) But in my opinion, this is the project that can deliver a usable and consistent Linux desktop to the average person the most effectively.

[0]: https://stopthemingmy.app/

[1]: https://blogs.gnome.org/tbernard/2021/07/13/community-power-...

[2]: https://ometer.com/preferences.html

[3]: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/1141

[cosmic_cheese]

Much of the frustration inspired by GNOME/GTK’s unthemability comes down to not having a few very simple knobs for users to tweak. Point in case, one of the primary reasons I used to theme GNOME desktops was to clean up Adwaita’s padding, which is utterly egregious for desktop usage. If GNOME just had a padding slider with 3-5 notches that’d go a long way and wouldn’t impair developers’ ability to build consistent apps in the least. Affordances like these are rarely given however and have to be fought for.

Aside from that, consistency and themability are not at all mutually exclusive. Back in the early days of OS X, theming by hacking system resource files (or patching them in memory via haxies[0]) was quite popular and for the most part, worked very well — generally, the only apps that didn’t play nice with themes were those sitting in the uncanny valley between native and custom, using bits of both, which tended to not be the highest quality applications anyway. This was way before Apple started pushing devs to parameterize their apps, too, and so similar theming capabilities today would work even better since themes can just tweak the parameterized fonts, colors, etc as needed to maintain coherence and usablity.

The real problem with GNOME/GTK is simply that it wasn’t designed with user customization in mind even as a remote possibility. A UI framework that did keep these things in mind combined with a strong dev culture of parametrization would make for a desktop that’s both customizable and consistent.

[0]: https://en.wikipedia.org/wiki/Unsanity

[aecsocket]

Interesting, I didn't know there was a theming presence on OS X! I agree with you in that consistency and themability can exist together (and I suppose your example proves that), and that had GNOME decided to prioritize themability we could have had something like that on the Linux desktop. I suppose this is a question of priority and where to allocate effort, rather than what is technically possible and not. Building a UI framework and HIG is already not an easy task, and making it customizable in the way you describe would be an even bigger burden on developers - many of which are, I assume, doing this work for free. But admittedly I haven't looked much into GNOME's funding or organizational structure, so maybe they are capable of it, but just haven't bothered.

[badsectoracula]

> I as an app developer want to guarantee that my app looks good on your desktop

When your app doesn't follow how my desktop looks it doesn't look good on my desktop. And unsurprisingly most modern Gtk3 and especially Gtk4 apps do not look good on my desktop.

What you actually mean here is that you want to guarantee that your app looks good on your desktop, not mine.

[aecsocket]

Yeah, I should have clarified that by "your desktop" I mean "your GNOME desktop" - i.e. "if you run GNOME, it'll look good no matter your preferences". But wrt "your desktop" - even if I wanted to, I couldn't guarantee that my app looks good on your desktop specifically, because I have no clue what your desktop looks like! Which is why I want to target a large common denominator of desktops instead, where I know it can look good.

The counter argument to that is "so let the user theme the app, to suit their own desktop", which would be a decent solution, but:

1. My vision for my app might conflict with your vision for your desktop. Maybe I want this button to be a light blue because it meshes well with some other elements in the app, but you want it to be a darker blue because it fits with your desktop's color scheme. What happens then?

2. This still doesn't guarantee that the app will look good. If you theme my app's home page, but don't theme the rest of the pages, then sure it'll look good at the home page - but as soon as you start using it, the look will fall apart. Or, what if I push an update to my app which adds a new page with a new kind of UI element? Do you really want to be maintaining your desktop theme for every single app you have?

3. This adds a burden on me as the developer to make parts customizable. This is the least convincing argument in this list IMO, since if there was better tooling and infrastructure for theming in GTK this wouldn't be a problem - but there isn't, so it is still a problem.

As a practical example, my app makes use of a WebViewGTK to display some info. I inject some custom CSS into this web view to make it look like Adwaita. This touches on points 2 and 3:

2. The webview has some UI widgets which aren't present in the rest of GTK, like a sticky header bar. You would have to manually maintain a stylesheet for this single element.

3. I now need to write a way to let users theme the custom CSS inside the webview, rather than just the CSS of the GTK widgets themselves. (I have already written this, but it's still a maintenance burden.)

[cosmic_cheese]

> My vision for my app might conflict with your vision for your desktop. Maybe I want this button to be a light blue because it meshes well with some other elements in the app, but you want it to be a darker blue because it fits with your desktop's color scheme. What happens then?

Probably something similar to how Apple platforms handle colors. Instead of providing a single static light blue, you have a couple options:

1. Use a “system color”, which is pre-tuned for optimal contrast, appearance, and usability and adjusts automatically when e.g. the user switches between light/dark mode or enables an accessibility setting related to color or vision

2. Define a light blue that’s actually multiple variants of the color bundled together, with each being optimal to various environments, with the UI framework choosing the right one depending on the situation

Arguably developers should be doing these things anyway for accessibility reasons. It’s not been good practice to use e.g. bare color hexes for quite some time now.

[JCattheATM]

> My vision for my app might conflict with your vision for your desktop. Maybe I want this button to be a light blue because it meshes well with some other elements in the app, but you want it to be a darker blue because it fits with your desktop's color scheme. What happens then?

The user trying to make your app match their desktop should 'win'. Your responsibility is to ship out an app and make sure it works in the way you want it to work.

If the people need to do more work to make it look good on their desktop (as I likely would running awesoemwm), that shouldn't be prevented, but it also need not be encouraged. It should at the least though be facilitated, certainly to a better extent than it is.

[II2II]

I generally prefer to live with defaults, so the lack of theming and user interface customization in Gnome is a good thing in my opinion. I tend to take the view that software that requires too much customization is poorly suited to my needs.

I suspect the thing that rubs a lot of people the wrong way with Gnome isn't so much the lack of customization or theming, but actual decisions behind how the user interface should work. People simply complain about the inability to customize Gnome as a reflection of how powerless they are to do anything about those decisions.

[robinsonb5]

> People simply complain about the inability to customize Gnome as a reflection of how powerless they are to do anything about those decisions.

But also that the Gnome philosophy "leaks" into the wider ecosystem, thanks to the dominance of Gtk.

(I use GtkWave as a waveform viewer. I have it installed systemwide, and it has proper menus. If I activate the oss-cad-suite environment [which is superb - this isn't a dig at that project] I have to remember to specify its full path when running it, otherwise I get a newer build shipped with oss-cad-suite, which has hamburger menus.)

[Vilian]

The upsude is a more stable applicationand less headaches for the developers

[shmerl]

KDE is more popular DE than Gnome these days and it's pretty flexible for theming.

[WD-42]

I highly doubt this. KDE users are far more vocal. Most people install Ubuntu (which is GNOME by default) use it and are happy with it and never comment about it on the internet.

It's near impossible to have a Linux GUI environment without GTK applications, while the opposite is not true for QT. I have a full desktop setup with GNOME and my machine doesn't even have the QT libraries installed.

[shmerl]

Some trends and stats on sites that collect info on DE usage indicate that:

https://www.gamingonlinux.com/index.php?module=statistics&vi...

It's totally expected for me, KDE is just better if you want any kind of customization.

It also comes preinstalled on Steam Deck for instance.

From some of the big GTK applications I use are Firefox and Gimp. That's about it, most of everything else is using Qt or is in the process of switching to Qt in my experience (like Audacity).

And from the above, Firefox isn't really using GTK due to some integration with Gnome, they just didn't want to write their own Wayland handling bits. It works on KDE all the same.

[zzo38computer]

I think there are many problems with GNOME and GTK. Some programs require GTK, but other than that I avoid them when I can. The theming is not the only problem, but it is one of them.

[robinsonb5]

For me its biggest issue (apart from the imposition of hamburger menus) is the awful keyboard handling in the file dialog.

[II2II]

> Sometimes I wonder why there isn't more enthusiasm around theming.

My guess: because it is difficult to develop software that can be themed and it is difficult to create themes that look good. Not only is it high effort, but it has relatively low returns. Themes mostly affect how things look and, ideally, have very little impact on functionality. I say ideally since, when there is an impact on functionality it is usually a negative one (e.g. buggy behaviour). Contrast that to a window manager or compositor: while it won't affect the functionality of individual applications (ideally), it does have a fairly significant impact upon how one interacts with the desktop as a whole.

[_fat_santa]

> Sometimes I wonder why there isn't more enthusiasm around theming

I can speak to this personally. I used to always tinker with various Linux desktops, themes, etc but nowadays I just use vanilla Ubuntu with zero theming modifications. There are two reasons for this:

1. Like others have said, theming is easy but consistency is hard. I've found that anything besides Gnome just turns into a shitshow where half your apps just don't theme properly.

2. It's a massive time sink. While I could create a very consistent theme, it would involve a massive time sink into dealing with all the edge cases. When I was in college and just used Linux "recreationally", I could justify spending a ton of time tinkering with my system and getting everything perfect. But these days I use Linux professionally so it's less about having a beautiful desktop and more about something that just works and gets out of my way so I can get my actual work done.

I should note that I still play around with other DE's and themes though I now do it all in VM's. I'm slowly building up my own theme stack on a Debian VM and once I get everything buckled up I might actually deploy and it use it on my primary machine.

[amarant]

I used to really enjoy theming and Riceing, but then I realised it was pointless: my monitor always looks the same, with a full screen IDE window covering up all my fancy themes

[keyringlight]

I think that speaks to another aspect, individual apps taking full control over how they're presented instead of inheriting whatever framework the DE is providing or the cohabitation of various KDE/QT/GTK/X/other, or electron framework defaults. Over on windows even when uxtheme skinning was in full swing it was the start of applications doing it themselves (winamp and quicktime come to mind), but I have the impression developers doing so made sure the extra effort had a payoff.

[robinsonb5]

I remember back in the day the apps most likely to have completely custom UIs tended to be scanner drivers. I'm not sure why!

[wlesieutre]

Because it always works well for like two applications and everything else looks half assed

[seba_dos1]

That's how it works in GNOME, yes.

[wlesieutre]

That and half of all new software being "draw a pretty picture, stick it in a webview" with no attempt to use the themeable widgets.

Even on Mac OS there used to be solid theming support (thanks, Unsanity) because software all used the system UI widgets. Not nearly as common anymore.

[AlienRobot]

Until I can change the color and font of everything on Linux the way I can on Windows XP, I'll never take Linux theming seriously.

Seriously, just make GUIs. That is the solution to ALL of Linux problems. MAKE THE GUIs!!! I can't select the background color of panes from a color picker and instead I have to manually edit text config files and create folders inside dotfolders. Ridiculous. It's 2025.

[pjmlp]

Probably because it gets tiresome after a while, I used to be big into Winamp themes, back in the 90's there were plenty of Demoscene and gamedev sites with desktop of the day, and what not.

After a while it loses the appeal, we decide to just use whatever defaults get offered, finetune one or two options and that is it.