3 ms·

It's a shame that, unlike with Win32, using WinUI places pretty harsh restrictions on which programming languages and environments you can use. Only C# and C++

by rossy 3y ago

It's a shame that, unlike with Win32, using WinUI places pretty harsh restrictions on which programming languages and environments you can use. Only C# and C++ are supported, the latter only with Microsoft compilers. For everything else, including Rust[1], Python and MinGW C/C++, there is no answer for OP's question, and the effect of this on the visual consistency of the Windows desktop is obvious - there is none. Every third-party app uses a different toolkit with a different look and feel, because the library providing the standard look and feel simply isn't available to the majority of developers. [1]: https://github.com/microsoft/windows-rs/pull/1836 https://github.com/microsoft/windows-rs/pull/1836

technion 3y ago
That's horridly confusing given MS has a Rust crate "Windows" has a "UI" Module that I guess is something different to WinUI. https://microsoft.github.io/windows-docs-rs/doc/windows/UI/index.html https://microsoft.github.io/windows-docs-rs/doc/windows/UI/i...
lowleveldesign 3y ago
Not to mention that WinUI is not supported on Windows Server. Therefore, if you need to deploy to server and desktop environments, it's better to stay with WinApi (WinForms) or WPF.
- pjc50 3y ago
  It isn't? That seems cripplingly stupid. WinForms is very old and doesn't do DPI, but one thing I like about it is that it always works.
vintagedave 3y ago
It's really hard to use with Win32 / the traditional Windows API too. Often APIs aren't exposed or documented -- consider the APIs to turn on the Acrylic or Mica looks in a window background, for example. There are a few Github repos that show how to do it but using reverse engineered APIs or constants. By comparison when Windows 7 was released, enabling glass was documented and usable from any language or framework. It's also not currently possible as far as I know to mix new controls and old controls in one window very easily - there are islands, but they seem on the macro scale (from when I last looked.) This makes updating apps difficult: changing a UI is an all or nothing upgrade per window. You can't just easily add WinUI to an existing WinAPI window in an app using a non-C#/Microsoft language. So people who have existing apps or use a non-MS dev environment are faced with enormous barriers. The ties to Microsoft languages and IDEs are also troubling. It's not technically MS-only, but it is _effectively_ MS-only. This is my personal account (I don't have a professional HN account) but I work at a company that produces a dev environment and IDE, and we run into these issues. I find that searching for my HN username and LinkedIn ("vintagedave LinkedIn") will likely let any reader (the OP, any reader, or u/ fassssst if you'd like to get in touch?) find me, and I'd be happy to speak on a personal or potentially professional level about issues with WinUI and what could be done to make it more accessible across dev environments and more easy to convert to or upgrade to.
grumblingdev 3y ago
> Every third-party app uses a different toolkit with a different look and feel This always infuriated me on Windows, and a big reason I moved to macOS. This is a great read: https://arstechnica.com/features/2012/10/windows-8-and-winrt-everything-old-is-new-again/ https://arstechnica.com/features/2012/10/windows-8-and-winrt... > ...the biggest problem is that USER [API] is essentially inextensible. If a developer wants to create, say, a menu that acts exactly like the standard operating system menu but with some small extra feature (for example, he might want to support the drag and drop, similar to the Favorites menu in Internet Explorer) he generally has no option but to reinvent the entire menu system from scratch. Seems like the failure of the Longhorn project really messed things up. It was suppose to replace the janky old win32 with .NET managed APIs. I just remember XAML/WPF/.NET being incredibly slow. And choosing a managed language for OS stuff seemed bad. I can't believe no one was doing a quick POC and saying: this is too slow. You have to give credit to Apple platform team. They have some real visionaries there. They had the guts to ignore garbage collection even when it was taking over the entire software industry. I guess MS just needed a competitor for Java.

by rossy 3y ago

technion 3y ago

That's horridly confusing given MS has a Rust crate "Windows" has a "UI" Module that I guess is something different to WinUI. https://microsoft.github.io/windows-docs-rs/doc/windows/UI/index.html https://microsoft.github.io/windows-docs-rs/doc/windows/UI/i...

lowleveldesign 3y ago

Not to mention that WinUI is not supported on Windows Server. Therefore, if you need to deploy to server and desktop environments, it's better to stay with WinApi (WinForms) or WPF.

pjc50 3y ago
It isn't? That seems cripplingly stupid. WinForms is very old and doesn't do DPI, but one thing I like about it is that it always works.

vintagedave 3y ago

It's really hard to use with Win32 / the traditional Windows API too. Often APIs aren't exposed or documented -- consider the APIs to turn on the Acrylic or Mica looks in a window background, for example. There are a few Github repos that show how to do it but using reverse engineered APIs or constants. By comparison when Windows 7 was released, enabling glass was documented and usable from any language or framework. It's also not currently possible as far as I know to mix new controls and old controls in one window very easily - there are islands, but they seem on the macro scale (from when I last looked.) This makes updating apps difficult: changing a UI is an all or nothing upgrade per window. You can't just easily add WinUI to an existing WinAPI window in an app using a non-C#/Microsoft language. So people who have existing apps or use a non-MS dev environment are faced with enormous barriers. The ties to Microsoft languages and IDEs are also troubling. It's not technically MS-only, but it is _effectively_ MS-only. This is my personal account (I don't have a professional HN account) but I work at a company that produces a dev environment and IDE, and we run into these issues. I find that searching for my HN username and LinkedIn ("vintagedave LinkedIn") will likely let any reader (the OP, any reader, or u/ fassssst if you'd like to get in touch?) find me, and I'd be happy to speak on a personal or potentially professional level about issues with WinUI and what could be done to make it more accessible across dev environments and more easy to convert to or upgrade to.

grumblingdev 3y ago

> Every third-party app uses a different toolkit with a different look and feel This always infuriated me on Windows, and a big reason I moved to macOS. This is a great read: https://arstechnica.com/features/2012/10/windows-8-and-winrt-everything-old-is-new-again/ https://arstechnica.com/features/2012/10/windows-8-and-winrt... > ...the biggest problem is that USER [API] is essentially inextensible. If a developer wants to create, say, a menu that acts exactly like the standard operating system menu but with some small extra feature (for example, he might want to support the drag and drop, similar to the Favorites menu in Internet Explorer) he generally has no option but to reinvent the entire menu system from scratch. Seems like the failure of the Longhorn project really messed things up. It was suppose to replace the janky old win32 with .NET managed APIs. I just remember XAML/WPF/.NET being incredibly slow. And choosing a managed language for OS stuff seemed bad. I can't believe no one was doing a quick POC and saying: this is too slow. You have to give credit to Apple platform team. They have some real visionaries there. They had the guts to ignore garbage collection even when it was taking over the entire software industry. I guess MS just needed a competitor for Java.