[Kwpolska]

Old toolkits make it much easier to set the text color of some label to #444, which looks fine on a light background, but is very hard to read on a black background. Setting it to some well-defined MutedText color requires more effort, and it requires the toolkit vendor to have thought about named colors in the first place (and if there are named colors, they might not be meaningful like Muted or Success, but instead ButtonBackground or TooltipText).

[CRConrad]

> Old toolkits make it much easier to set the text color of some label to #444, which looks fine on a light background, but is very hard to read on a black background.

That's why in for example Windows, up until ~early/mid W7, you could set both TextCoulour and BackgroundColour to whatever contrast you wanted, and then all apps respected that.

[liontwist]

You can change background and button colors too.

Other point is noted. But let’s compare the alternative:

1. Fiddle with a config file for each app for a week. Distro includes this in dark mode set. 2. Each app writes custom code to listen for and adapt to dark mode events.

[Kwpolska]

Let me restate the problem: I set my system-wide window background to black and text color to white. An app developer sets a label to dark gray text and default/transparent background. The end result is that I cannot read the label. Or the developer uses black icons on the toolbar — and I cannot use the toolbar, because I can’t see anything.

macOS introduced system-wide dark mode a few years ago, but app developers had to recompile and opt into it. This was done so that they could adjust their artwork and overridden colors to it. Windows 10 added dark mode, but only for "modern"/UWP apps. Classic Win32 apps need to implement their own dark mode with custom themes/controls (like Explorer does).

[alkonaut]

Black-on-black is a big problem. You can't make an app use a dark mode unless it's painstakingly crafted to support it. Only trivial apps would work by changing some system-wide palette. Also, if there is any artwork (button icons etc) then that has to be done in two or more sets, for varying backgrounds. Few icons would work well on both a light and dark background.

[CRConrad]

> Black-on-black is a big problem. You can't make an app use a dark mode unless it's painstakingly crafted to support it.

Maybe not now, but back in the day, that was utter BS. You pretty mucch had to go out of your way not to have your app use whatever colour palette the user had decided on. Well, on Windows, at least. (And here I thought people used to brag about programming tools on Linux being better than on Windows; are you saying that in at least this respect, they werern't better even then?)

> Only trivial apps would work by changing some system-wide palette.

That must be why almost ALL Windows apps up until at least ~2010 worked just fine by changing the system-wide palette.

> Also, if there is any artwork (button icons etc) then that has to be done in two or more sets, for varying backgrounds. Few icons would work well on both a light and dark background.

Oh, it worked well enough. (Mostly, I suppose, by the super-advanced trick of using colours pretty much midway between light and dark.)

[liontwist]

What's still being missed from the discussion is that Motif allows per-app config, with queries that reach into the app's UI tree, and pick out individual elements.

A custom config can be made for each program to addresses all idiosyncrasies and that could be shipped with the distro as "dark mode" without any code change.

[CRConrad]

I don't think that was entirely missed: AFAICR, I pointed out somewhere that in that case, it's up to the app developer not to screw it up. If they set the foreground colour but not the background, or vice versa, they risk getting both so close to each other that the lack of contrast makes text illegible. This is so obvious that on such systems, the fault is totally with any app developer that does this.

[CRConrad]

> Let me restate the problem: I set my system-wide window background to black and text color to white. An app developer sets a label to dark gray text and default/transparent background.

Yeah, that's a moronic developer. So what? Moronic developers have always existed, and still do. You can't blame toolkits or OSes for their existence.

> Classic Win32 apps need to implement their own dark mode with custom themes/controls (like Explorer does).

Only since Windows was enshittified from ~Windows 8. (Though the first signs came in late W7.) Before that, you set whatever systemwide theme you wanted -- Light, Dark, Hilarious Clowncar -- in the Control Panel, and all apps followed that.

Well, almost all... Some, then many, fuckwit companies refused to follow the user's system-wide settings, and of course now nobody does because there are none. (Ironically, among the first offenders, and certainly the most influential, was Microsoft itself.)

But old Windows was far better at these things than current, and AFAICT at least as good as, possibly better than, any current Linux DE.

[liontwist]

> Windows... at least as good as, possibly better than, any current Linux DE.

As a Linux enthusiast I agree. Microsoft built windows for utility, and did a lot of research to determine what worked. It took all the best ideas from other UI toolkits and refined them.

It's absurd that making a scrolling list of ~5000 items is a performance problem for modern applications when it's completely solved in Windows 95.

[CRConrad]

NB: "old Windows was far better at these things than ... any current Linux DE", where "these things" is explicitly the breadth of desktop UI user settings, and to a slightly lesser degree, applications respecting them. Not saying it is, or ever was, better at anything else.