5 ms·

On the Windows side, isn't it a side-effect of the shift from standardized common controls to WPF that happened around the vista time-frame? It's much harder t

On the Windows side, isn't it a side-effect of the shift from standardized common controls to WPF that happened around the vista time-frame? It's much harder to provide consistent user theming against non-standard controls. Similarly, on the early web you could theme sites easily with your browser settings, but as theming power shifted to web developers with CSS, that capability melted away.

squiggleblaz 6y ago
> On the Windows side, isn't it a side-effect of the shift from standardized common controls to WPF that happened around the vista time-frame? It's much harder to provide consistent user theming against non-standard controls. Not directly. If you code in Win32 on modern Windows, you pretty much have to enable themed widgets. Once you've enabled themed widgets, you give up the ability for the user to control the appearance. I don't believe there was any technical reason for the change; it was the desire to have themed widgets (or in plain English: branded widgets) which made them uncustomisable.
- marwis 6y ago
  Most native desktop development in Windows is nowadays based on WPF and as parent mentioned WPF broke the consistency with the rest of Win32. WPF does it's own vector-based drawing that completely ignores legacy Win32 API except for some basics such as control colors. Even its standard Windows theme is a poor imitation of actual Windows style - you can easily spot WPF apps with default theme because they stick out like an eye sore.
  - cgrealy 6y ago
    Is WPF actually that popular though? Honest question... last time I did any WPF dev was 2008 and I haven’t really seen it used much since. MS certainly aren’t hyping it much (although that could just be the decline of the desktop app in general). My impression was that it wasn’t worth it for small apps and not performant enough for things like CAD, etc.
    - marwis 6y ago
      It's highly popular for enterprise line of business and industrial apps you'll never hear about. Some of it is moving to web but web is not really competitive in terms of performance and integration (lots of legacy COM/ActiveX or closed source native libraries to integrate with). The only realistic alternative is using WinForms (more dead than WPF) or Qt but then you have to hire C++ programmers. It's certainly perfomant enough (much faster than web) for complex apps like CAD - the actual editor/renderer won't be WPF of course but some custom OpenGL/Direct3D code.
signal11 6y ago
I do agree that the modern love for “dark mode” has made developers realise — albeit in a limited way — that there is a pent-up demand for theming. Products who do theming well tend to be popular among their users — eg IntelliJ and VSCode of course, but tbh Emacs and vim are no slouches in this regard.
wongarsu 6y ago
Using the configured system colors is still trivial even with custom WPF controls. CSS2 also exposes system color settings, even though the selection is a bit limited ("inactivecaption", "threedhighlight" and friends).
WorldMaker 6y ago
WPF controls are still system provided/standardized "common" controls, though. Up until recently (.NET Core 3) all WPF releases were still Windows releases. 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.
- richard_todd 6y ago
  I hear what you're saying, and I agree that MS could have done much more to allow consistent theming by the user. But, I also know that even a beginner WPF tutorial shows how to arbitrarily adjust controls with a resource dictionary. Meanwhile, I don't recall ever learning how to change the color of a win32/c++ button short of taking over the entire drawing responsibility (I'm sure it's possible but that's beside the point). So as a result of that emphasis, it seems to me a lot more WPF/UWP apps use arbitrary non-standard colors/fonts/highlights/animations, which would be completely at odds with user-selected themes. I know mine did, anyway, so I guess I was part of the problem!

squiggleblaz 6y ago

> On the Windows side, isn't it a side-effect of the shift from standardized common controls to WPF that happened around the vista time-frame? It's much harder to provide consistent user theming against non-standard controls. Not directly. If you code in Win32 on modern Windows, you pretty much have to enable themed widgets. Once you've enabled themed widgets, you give up the ability for the user to control the appearance. I don't believe there was any technical reason for the change; it was the desire to have themed widgets (or in plain English: branded widgets) which made them uncustomisable.

marwis 6y ago
Most native desktop development in Windows is nowadays based on WPF and as parent mentioned WPF broke the consistency with the rest of Win32. WPF does it's own vector-based drawing that completely ignores legacy Win32 API except for some basics such as control colors. Even its standard Windows theme is a poor imitation of actual Windows style - you can easily spot WPF apps with default theme because they stick out like an eye sore.
- cgrealy 6y ago
  Is WPF actually that popular though? Honest question... last time I did any WPF dev was 2008 and I haven’t really seen it used much since. MS certainly aren’t hyping it much (although that could just be the decline of the desktop app in general). My impression was that it wasn’t worth it for small apps and not performant enough for things like CAD, etc.
  - marwis 6y ago
    It's highly popular for enterprise line of business and industrial apps you'll never hear about. Some of it is moving to web but web is not really competitive in terms of performance and integration (lots of legacy COM/ActiveX or closed source native libraries to integrate with). The only realistic alternative is using WinForms (more dead than WPF) or Qt but then you have to hire C++ programmers. It's certainly perfomant enough (much faster than web) for complex apps like CAD - the actual editor/renderer won't be WPF of course but some custom OpenGL/Direct3D code.

signal11 6y ago

I do agree that the modern love for “dark mode” has made developers realise — albeit in a limited way — that there is a pent-up demand for theming. Products who do theming well tend to be popular among their users — eg IntelliJ and VSCode of course, but tbh Emacs and vim are no slouches in this regard.

wongarsu 6y ago

Using the configured system colors is still trivial even with custom WPF controls. CSS2 also exposes system color settings, even though the selection is a bit limited ("inactivecaption", "threedhighlight" and friends).

WorldMaker 6y ago

WPF controls are still system provided/standardized "common" controls, though. Up until recently (.NET Core 3) all WPF releases were still Windows releases. 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.

richard_todd 6y ago
I hear what you're saying, and I agree that MS could have done much more to allow consistent theming by the user. But, I also know that even a beginner WPF tutorial shows how to arbitrarily adjust controls with a resource dictionary. Meanwhile, I don't recall ever learning how to change the color of a win32/c++ button short of taking over the entire drawing responsibility (I'm sure it's possible but that's beside the point). So as a result of that emphasis, it seems to me a lot more WPF/UWP apps use arbitrary non-standard colors/fonts/highlights/animations, which would be completely at odds with user-selected themes. I know mine did, anyway, so I guess I was part of the problem!