I'm aware that Acrylic controls are XAML only. I'm referring, though, to the UI support itself: glass, blending, the small amount of noise added, etc. In Windows 10, glass is not supported any more - except it is, because it is used in Acrylic. How? Well, using the same APIs as glass in Win7, but with small tweaks that are undocumented. Some people including myself have attempted to reverse engineer some of the new flags that are required. It looks likely that Acrylica can be completed done in a plain old WinAPI app using glass and a Direct2D canvas - except that some of that is undocumented.
If I'm wrong here, and you can point me at non-.Net API documentation, please do.
> Complaining that you need WinRT to access modern UI effects seems a bit like complaining you need DirectX to access modern GPUs
That's not what I said.
You do not need WinRT to access modern UI effects, but Microsoft seem to be requiring to you to use WinRT to access modern UI effects. That is, requiring you to use their libraries, their development tools, and so forth. It is not open, and it is anti-competitive.
The C++/WinRT library I linked to started outside of Microsoft (as "moderncpp"), was acquired, and is still open source. Microsoft isn't requiring their own development tools to build WinRT (there's also open source React Native off the top of my head), it's just that so far not a lot of non-Microsoft developments tools have targeted/needed to target WinRT to date.
They aren't requiring you to use their libraries, they are requiring you to use their modern API (WinRT).
Documentation site: https://docs.microsoft.com/en-us/windows/configuration/windo...
> Consider the APIs for the Acrylic UI, which is implemented in the WinAPI (not .Net) but is only accessible from .Net applications.
The Acrylic controls are XAML controls built on System.Composition [1] and Windows.UI.Composition [2] APIs. C++ (and any language that can compile to it) has access XAML and System.Composition just like .NET, it just needs to speak WinRT. C++/WinRT was just released in the Windows SDK which just uses "real" C++ headers and no language extensions to interface with WinRT. [3] That should make it even easier for other languages to explore how to support WinRT applications, which for the most part if a language can support COM it can figure out how to support WinRT.
Complaining that you need WinRT to access modern UI effects seems a bit like complaining you need DirectX to access modern GPUs and can't just brute force VGA bit buffer your games anymore.
(My only complaint with the Fluent UI APIs is there doesn't seem to be access from the HTML/JS side of the fence, given that's the important "third platform" after C++ and .NET. I'd like to see PWAs have the ability to use at least some of the Fluent and/or Acrylic effects, but I haven't seen a useful sample of that yet.)
[1] https://msdn.microsoft.com/en-us/library/jj126278.aspx [2] https://docs.microsoft.com/en-us/uwp/api/Windows.UI.Composit... [3] https://msdn.microsoft.com/en-us/magazine/mt745094.aspx