Remembering Windows 3.1 themes and user empowerment

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.

> We all are mostly average users.

If by "we" you mean the population of HN - that is blatantly false. The average HN user is far more technically sophisticated than the average computer/phone user.

>> The average user does not do this.

This is completely true, and not "paternalistic" in the least - it's a statement of fact.

> There is not really any difference between your father and you.

Absolutely false. My father, as do most of the fathers I know, are profoundly disinterested in customization and learning more about their devices - even after I show them some of the stuff that they could do, and offer to teach them. It's simply not interesting to them - they want to do workworking, or something.

> My mother wants to play with things like everyone else.

Then your mother is different than most peoples' - including mine. My mother does not want to play with her phone - she wants to use it to get something done, whether that be talking with her friends or watching a video. This also describes my father, and the parents of the majority of people I know.

Now, sure, most humans want to "play with things" in the general case. However, that does not extend to every kind of object (e.g. car, gun, workbench, computer, house) for every person, and what's more there is a tremendous amount of variability in the drive that each person has to customize each of those things. The fact that your mother might passingly be interested in changing the wallpaper of her phone does not in any way make her comparable to the /r/unixporn poster who has spent literally hundreds of hours on a single visual theme.

> But we, the developers, don't allow them, and we put them into walled gardens without ever giving them a choice. Because we are smarter and we known better, and we are doing it for their own good.

That's what the post is arguing against. You seem to be under the impression that separating "users" and "developers" implies taking control away from the former - which is false. Users are different than you - and you should give them power.

The issue isn't necessarily caused by the controls themselves or even the theming engine baked into WPF. Had Microsoft prioritized it, WPF might have had stronger system theming/retheming out of the box. It could have provided stronger design themes and more user choice in adopting theme. There's a brief window in the Zune development life cycle where they almost delivered exactly such a thing for WPF. IIRC there were 3 or 4 prominent Zune themes and easy style sheet swaps (including on the fly) to switch between them in WPF and those base stylesheets were almost productionized and included in the system WPF resources. (Then of course we all know what happened to the Zune and things moved to other platforms.) They still likely would have been opt-in because Microsoft prioritizes backwards compatibility, but they were a glimpse to the timeline where Microsoft had maybe done that sort of design work further ahead of time and forced it to be opt-out by default. (Admittedly which they tried and failed to with Windows 8 because developers complained too much that the opt-out was too hard and we'd already lost the war for "native controls/native themes" by that point to corporate/enterprise designers and branding efforts.)

Of course the "two worlds" problem of having multiple "competing" systems controls between the classic Win32 world and the WPF/XAML world is unlikely to ever be solved, given backwards compatibility assurances, but having "two worlds" shouldn't have stopped Microsoft from a single unified theming engine had they the initiative/prioritization. There's even hints that some people at Microsoft were considering it back before WPF was launched. WPF was always a partial shell of the "Avalon" dream of Longhorn's tumultuous development.