If everyone renders buttons in a custom way, they bypass the native, theming-capable, accessible-by-default system controls. As long as product managers are happy, it doesn't matter that users aren't.
For Apple it was about delivering a consistent branded experience, for the GNOME and KDE communities it was about being able to consistently customize the experience.
In Windows? Always a free-for-all of such heavy customization on the side of the third-party applications that a Windows look and feel was never really a thing, nor was theming because of the same thing.
Then GNOME 3.0 came and they went for the consistently branded experience approach, and you were left with a black and gray desktop environment that at best tolerated customization.
And it works alright, but Desktop Linux at most you'll get to work alright, the third party app ecosystem is small, without the feeling of ownership and freedom that an end-user can have with their system, customizing not the kernel but the things they're actually interacting with, what's left? An unremarkable desktop environment with few applications, that you'll want to replace with macOS as soon as you have the money.
The "dark or light" theme we have today is an absolute joke by comparison.
Many Gtk-engines were also much faster in terms of pure rendering speed.
Another issue as mentioned is that per-control CSS skinning breaks easily with custom themes. Instead of using system colors devs often hard-code a custom look.
Finally, some programs go for a fully custom theme that doesn't even work properly without. Darktable is one example. Darktable looks cool, but a long time I had a hard time reading it's controls since it didn't respect system's font sizes nor it allowed to change it. The contrast was poor. It now comes with several themes, but nothing matches my system theme, which is more accessible.
As much as I love darktable, I'd skip the custom UI any day.
Ironically, you used to be able to use system colors via CSS. Like it usually happens on the web, that feature was also removed because of security reasons - apparently it made it easier for scammers to render fake system popups.
After years of using MacOS, I made a commitment this year to use, support, and develop for Linux on a regular basis.
Starting off with little knowledge of GTK, I progressed from "hello world" to working on my first app, but end user customization has always been close to my heart, so naturally I started looking at what it takes to bring a GTK desktop app from "stock system UI" to "developer and user themable".
All this to say, it could be my inexperience, but I'm finding that GTK seems to be very much "all or nothing" here. I can use all the default widgets and be 100% native, and I can "* { background-color: pink; }" my way into a blank canvas, but if I want to make custom controls that build on the user's system theme and whatever accessibility he/she has set up for him/herself, I'm on my own to make my best guesses.
There's no reliable way to determine whether the user is scaling text, using a dark or light theme, or something super high contrast for accessibility. I can try to query some built in widgets and make decisions from there, but I've found that quite flaky as well.
Moreover, even finding which classes to assign to widgets to "piggy back" off the common system colors when building my own widgets is a chore of hunting through themes like Adwaita to find the piece of the system widget I'm trying to utilize. It's not quite WPF "copy the entire widget's XML and re-implement it from scratch to customize it" bad, but for as powerful as the CSS support seems to be in GTK, it feels like there's a layer in between "full system UI" and "total rebrand" that's missing.
So for example you should be using this to use the user's foreground and background color:
color: @theme_fg_color;
background-color: @theme_bg_color;
I would suggest against trying to piggy back on built-in CSS styles; usually with the default widgets you want to favor composition over inheritance. But if you really need to you can use the GTK inspector to look at the styles on any given system widget, that should be a bit easier than grepping through the CSS.
I still think it comes down to branding though, even with those totally customizable environments. The difference is, it's not someone else's brand. I get to turn my environment into my own 'brand'.
That's always kind of been the appeal of theming and customization to me, the ability to remove someone else's brand from my computer and replace it with my own.
In Windows 2000 and earlier, before system file protection, it was possible to use a resource editor and/or a specially crafted BMP file to change system icons, boot animations, start menu imagery, login screen, etc. With a hex editor you could change any UI text, too. I had a heavily customized W2K alongside my heavily customized Linux (even started working on my own graphical boot animations and graphical login for the text console as part of a media-focused distro project I had joined).
it still is, just look at how neat things in https://reddit.com/r/unixporn/ look
that's definitely not my experience with KDE, I just have to set a theme on the system settings and 99% of apps take it (e.g. with this theme in my case: https://www.reddit.com/r/unixporn/comments/b49l7k/kde_sweet_...).
Eh? Theming was fizzling out by 2005, which starts to correspond to the rise of OS X and Macbooks.
Enlightenment came out in 1997 and was all about theming. But theming predated E by a few years already. https://en.wikipedia.org/wiki/Enlightenment_(software)
This is what I would call the "golden years" for Linux theming. Late '90s to early 2000s.
> Windows look and feel was never really a thing, nor was theming because of the same thing.
I mean. Did you even read the article you're commenting on? Windows 3.11 had themes. Windows 95 had Microsoft Plus: https://en.wikipedia.org/wiki/Microsoft_Plus!
> Then GNOME 3.0 came and they went for the consistently branded experience approach
This happened way before GNOME 3 was a thing. GNOME 2, Xfce, and others stopped their obsession with Windows and started thinking about OS X, which was eating the desktop UNIX lunch.
I don't know man, it's what I saw as more and more people came to Ubuntu with Windows Vista flopping, and they came with expectations of a flashy UX and a dynamic growth of the platform. Lots of theming, lots of hopeful mockups and GTK+ struggling to support transparency as theming engines hacked it in, the race to incorporate compositing and having everyone's graphics cards actually work.
I get it that there was a lull during the transition between GNOME 2 and GNOME 1, many of the myriad themes you found on repos in 2005 were ports of GTK 1.X themes, no more. But the influx of Windows users injected a lot of vitality into the theming scene.
> I mean. Did you even read the article you're commenting on? Windows 3.11 had themes. Windows 95 had Microsoft Plus: https://en.wikipedia.org/wiki/Microsoft_Plus!
Precisely, long-since retired technology. The Windows XP era lasted 8 long years, as people for the most part skipped Vista. It just wasn't very prominent and crazy custom UIs were rampant.
The scrollbar in System Settings is impossible to customise (through the GUI). Tray icons and log-off dialogue icons and the task bar appearance cannot quickly or easily customised because due to "theme"ing changing one thing also changes the other.
The maintainers screwed up and it was all downhill after version 3. Each major version introduced an incompatibility that meant that some users were forced to abandon, e.g. KDE Classic icons or window decorations BⅡ https://cdn.pling.com/img//hive/content-pre2/5965-2.png or Crystal https://cdn.pling.com/img//hive/content-pre1/13969-1.jpg
That is not my memory. If you were careful to use just programs from KDE/Qt or GNOME/GTK, then this was about right, but every graphics toolkit had its own way of handling theming, and if you combined programs built with multiple graphics toolkits (additionally: Motif, Java, raw X) that would not respect your configuration.
If an app can't survive on its usefulness alone, it probably shouldn't exist.
As a user, if an app doesn't have a native UI, I disregard it unless I need it for a specific and mandatory use.
On the flip side I want me email client, my desktop authoring tools and admin tools to all look and act the same.
(The blue/grey theme that came later was far less performant; I mean the original dark green/black theme.)
And WinAmp would open & play literally any format under the sun. WMP was limited to something like MP3 and WMA. (And maybe WAV.)
That's how VLC became so popular. They realized "sorry, you don't have that codec" is only a bureaucrat's idea of good UX so they shipped every codec in software.
Well, yes and no. Remember, Windows Media player used to be this:
https://www.windows-media-player.com/wp-content/uploads/2019...
and without system-installed codecs, which were hard to come by for something like MP3 files, it was basically useless; you could play MIDI files through your shitty OPL-3 FM synth and that's about it.
Winamp came with a remarkable set of capabilities: - A bunch of useful codecs out of the box - An extensible plugin system, with input, output, general, and visualization plugins - Skinnable UI
The secret sauce was the extensibility, really. You could kill hours just tweaking your Winamp, installing crazy audio effect plugins, and so forth. It was really a new breed of application for most users who were used to really business-like apps.
https://i.imgur.com/DuxpATX.gif
It's what started my desire for better sound quality, pursuing better equipment and assembling my own crazy dsp stacks in order to... well, enhance sound quality, which I do to this day!
Dealing with equalizers, dynamics processors, crossover, convolvers/IR, applying hrtf/hrir found on the net, using room eq wizard to try and improve speaker/room response, buying a damn binaural microphone so I could make my own ears impulse responses... I ended up learning a lot about the subject, form such a tiny "seed"
Now that screen resolutions vary quite a bit I suppose it wouldn't work as well as when all monitors were mediocre 800x600 or glorious high res 1024x768. Ah, the nostalgia.
I disagree rather strongly with this. You should use the UI elements that make sense. It doesn't make sense for Maya or Blender or Photoshop to constrain themselves to whatever Microsoft picked out for them to use. The palette of native widgets and native UX methods is woeful across all systems. It's constrained to the set of generic elements which are applicable to some theoretical business application, like Word or Excel (which, I must point out, could neither be implemented fully in terms of native UI widgets alone).
> If an app can't survive on its usefulness alone, it probably shouldn't exist.
Form follows function. And I would argue the opposite of the point you're making: if an app can exist purely in terms of native UI widgets, does it even need to exist? I can think of almost no useful apps outside of basic utility apps (file copying, patching, app installers, etc.) that are useful and fully native UI.
> You should use the UI elements that make sense. It doesn't make sense for Maya or Blender or Photoshop to constrain themselves to whatever Microsoft picked out for them to use.
The nuance in my beliefs is that if UI elements aren't available for the function, then apps should absolutely build custom UI. I agree with you there.
It's when you have a basic app that can entirely use native controls and chooses to forego them to do everything custom that I have a problem with.
For my particular example, we were building a cryptocurrency wallet for a new blockchain. It was simple enough to use entirely native controls but definitely didn't need a custom UI.
http://wp.xin.at/wp-content/uploads/2017/08/photoshop-cs6-fu...
That said, I'm not entirely sure Photoshop makes a strong point for making custom UI controls, since besides the primary interaction of pointing and clicking on an image, everything else is either dialogs, menus, and toolbars --- all of which are available in the native UI.
What we are most likely seeing is push-back over some of the excesses of themes. Branding is likely part of that, but the astounding number of controls likely played a negative role in the user experience as well.
What's more recent is that the OS vendor now considers UI font and color choices part of their brand, and thus fixed them immutably for "consistency" i.e., to advertise the Apple-ness of the Apple UI even in screen shots of the OS in action.
Page curls. Page curls everywhere!