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.

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

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