4 ms·

At the same time it's common to hear "how does this not support high DPI?" or "How does this app not have a dark mode, it's 2024!" etc. Modern toolkits just do

At the same time it's common to hear "how does this not support high DPI?" or "How does this app not have a dark mode, it's 2024!" etc. Modern toolkits just do a lot of stuff that older toolkits didn't. Some times at the expense of not being as quick to get off the ground as VB was. The original winforms implementation in the early 2000's was pretty close to VB in terms of efficiency but its warts were numerous, e.g. the DPI used in the designer view (when writing the code) affected what happens when you run it, and so on.

Grumbledour 2y ago
It used to have darkmode++ back in the day, because windows allowed you to just choose all the controls colors in any way you wanted. Of course it lacks features we want today, especially things we are used to from the web, like highlighting fields with errors in them etc., but I often think new features can't entirely explain why the newer toolkits are so much less ergonomically useable.
- CRConrad 2y ago
  > It used to have darkmode++ back in the day, because windows allowed you to just choose all the controls colors in any way you wanted. It's amazing how almost nobody in discussions like this ever acknowledges that. Are all the GNOME kiddies just so determined never to admit anything else could be better at anything, or do they genuinely not know how much shittier stuff is now than Windows was only a dozen years ago? > Of course it lacks features we want today, especially things we are used to from the web, like highlighting fields with errors in them etc., Yeah, that's unfortunately true. But, since the definition of "What is an error?" is up to the app, it feels kind of excusable that pointing it out in the UI also did. Sure, could have been easily fixed with two more settings -- ErrorTextColour and ErrorBackgroundColour, something like that... But absent those, clear reds and yellows work pretty well (for the non-colourblind). You'd have to intentionally set your UI to be pretty garish for those to be taken for "normal" colours. > but I often think new features can't entirely explain why the newer toolkits are so much less ergonomically useable. All I can come up with is "Kids today, sigh".
- Kwpolska 2y ago
  Changing control colors tends to break, since developers may set the text color to "really dark grey" without changing the background, so you get black on black.
  - CRConrad 2y ago
    For precisely this reason, only idiot developers ever did that.
liontwist 2y ago
Dark mode would have been trivial with old toolkits because they used standardize look and feel. In fact motif lets you customize the color scheme through a text file. Which can make each app fit the appearance of the given desktop. Old guis also had more accssibility features. The only thing modern ones have going for them is animation and visual customization.
- Kwpolska 2y ago
  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 2y ago
    > 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 2y ago
    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 2y ago
      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).

Grumbledour 2y ago

It used to have darkmode++ back in the day, because windows allowed you to just choose all the controls colors in any way you wanted. Of course it lacks features we want today, especially things we are used to from the web, like highlighting fields with errors in them etc., but I often think new features can't entirely explain why the newer toolkits are so much less ergonomically useable.

CRConrad 2y ago
> It used to have darkmode++ back in the day, because windows allowed you to just choose all the controls colors in any way you wanted. It's amazing how almost nobody in discussions like this ever acknowledges that. Are all the GNOME kiddies just so determined never to admit anything else could be better at anything, or do they genuinely not know how much shittier stuff is now than Windows was only a dozen years ago? > Of course it lacks features we want today, especially things we are used to from the web, like highlighting fields with errors in them etc., Yeah, that's unfortunately true. But, since the definition of "What is an error?" is up to the app, it feels kind of excusable that pointing it out in the UI also did. Sure, could have been easily fixed with two more settings -- ErrorTextColour and ErrorBackgroundColour, something like that... But absent those, clear reds and yellows work pretty well (for the non-colourblind). You'd have to intentionally set your UI to be pretty garish for those to be taken for "normal" colours. > but I often think new features can't entirely explain why the newer toolkits are so much less ergonomically useable. All I can come up with is "Kids today, sigh".
Kwpolska 2y ago
Changing control colors tends to break, since developers may set the text color to "really dark grey" without changing the background, so you get black on black.
- CRConrad 2y ago
  For precisely this reason, only idiot developers ever did that.

liontwist 2y ago

Dark mode would have been trivial with old toolkits because they used standardize look and feel. In fact motif lets you customize the color scheme through a text file. Which can make each app fit the appearance of the given desktop. Old guis also had more accssibility features. The only thing modern ones have going for them is animation and visual customization.

Kwpolska 2y ago
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 2y ago
  > 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 2y ago
  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 2y ago
    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).