Comment by Const-me | Hacker News Reader

Comment by Const-me | Hacker News Reader

For requirements like that, I typically write WPF C# frontend, combined with C++ backend. Compared to ImGui, in WPF you’ll get a GUI designer, styling which allows easy dark mode, data bindings, data templates, animations, IDE support like live visual tree inspector, accessibility support, and more.

If you use the legacy .NET 4 framework, the .NET runtime will come pre-installed on modern Windows. If you compile your C++ DLL with static C runtime, your C++ DLL won’t have any dependencies apart from OS components like kernel32.dll.

If you insist on having a single EXE you’ll need to bundle it and extract, but the additional code for the P/Invoke to work is like 4 lines of that code, call LoadLibraryW from kernel32.dll early on startup, before using any stuff with [DllImport] from that DLL.

I do not recommend C++ CLI. Write normal C++ which compiles into native code without any weird metadata. You can use C APIs, or COM interop with ATL, or check this library of mine https://github.com/Const-me/ComLightInterop/

If you start with this approach (as opposed to refactoring a C++ app you already have) you’ll find out that you need substantially less C++ than you expected. Essentially, C++ is only required for 2 things: CPU-bound number crunching, and code which consumes large C or C++ libraries (Windows SDK is huge and pieces like D3D or MediaFoundation require C++). It’s much easier to do everything else in C#, as the language and especially the standard library are just better.

I do not recommend C++ CLI.

Can you elaborate on why?

I looked at various ways for interop between C# and C++ over the years, and overall found C++/CLI to be the best overall for our particular application types: it's a separate layer bewteen a C++ backend (which is also used in other non-gui applications), with a windows-only WPF desktop application on top. Mainly because the C++/CLI code itself is simple, readable and fairly effortless to write and maintain. A bit repetitive at times though, but that's going to be the case for any such layer AFAIK. Integration on the C# is seamless, with code completion etc, and C# interfaces can be implemented in C++/CLI directly for instance. The initial setup takes some work but with conversion between common types implemented (ability to e.g. IEnumerable<ManagedT> <-> std::vector<NativeT> or std::iterator<NativeT> etc) it's all pleasant and good.

or check this library of mine https://github.com/Const-me/ComLightInterop/

Gotta say this looks neat, but it's exactly the type of code I'd rather not write: UUIDs, bunch of macros, unclear mapping between return types (HRESULT vs bool), having to declare same interfaces both in C++ and C#, ...

> Can you elaborate on why?

The language is only supported in a single compiler, and is specific to Windows.

The language is based on both C++ and .NET runtimes, and when I used it (admittedly, it was many years ago) I didn’t like the usability consequences. These two runtimes interact in a weird way. It’s hard to compose data structures which contain both managed and unmanaged pieces, see that question https://stackoverflow.com/q/10523268/126995 You can’t include Windows SDK headers in CLI code, not gonna compile: https://stackoverflow.com/q/26502283/126995 Same applies to most third-party C and C++ libraries.

So with CLI you have 3 languages instead of just two: C#, C++/CLI, and classic C++.

> it's exactly the type of code I'd rather not write

I have used that library in multiple projects in the last 5 years, for Windows and Linux platforms including ARM Linux, both open source and commercial. It worked great for my use cases.

Here’s an open-source example of a relatively complicated COM interface implemented on top of ComLightInterop. C# interface: https://github.com/Const-me/Cgml/blob/master/CGML/CgmlNet/iC... C++ interface: https://github.com/Const-me/Cgml/blob/master/CGML/Cgml/API/i... C++ implementation: https://github.com/Const-me/Cgml/blob/master/CGML/Cgml/D3D/C...

As you see it has very few macros, no bool returning methods, very clean API between managed and unmanaged parts, and most importantly very readable idiomatic codes on both sides of the interop.

I’d like to add that if you make mistakes when writing these C++ and C# projection of a COM interface you’ll find very soon because it’s likely to crash on first use due to /GS compiler switch. Also trivial to debug and fix because VS supports mixed-mode debugging.

I have been trying to learn WPF for a long time, but have drifted into web apps.

Can you point me to any good resources to be able to make complex multi window apps in it?

I have good experience in Windoes forms and am well versed in c# and dotnet.

I’ve learned WPF long ago, and I no longer remember how specifically I did that. Still, that introduction seems pretty good at the first sight: https://wpf-tutorial.com/

Learning is easy, it’s very user friendly and IDE support is great. Mastering the framework for complicated GUI is harder. Here’s a few tips.

Treat XAML the same way as any other source code. Keep it human readable: write comments (the syntax is the same as in XML i.e.  ), and use proper indentation (I often use tab size = 2 for XAML files). When a particular window or control grows too huge, consider moving large pieces into separate XAML files with a user control or maybe a resource dictionary.

MVVM design pattern is great, use it whenever possible. Don’t forget to implement INotifyPropertyChanged and/or use ObservableCollection<T> for dynamic things. Having said that, I tend to avoid opinionated MVVM frameworks like Caliburn.Micro, IMO these things sacrifice simplicity for testability.

Sometimes for complicated UX use cases like drag/drop or mouse painting handling these input events in code behind is way simpler than trying to stick with MVVM. Luckily these approaches compose rather well; it’s possible to use MVVM for most of the UX and code behind logic only in the few places where it simplifies things.

Similarly, for diagrams or similar GUI you can directly create and manipulate these UI elements with C#, placing then on a canvas. Technically possible to do in MVVM-y way e.g. an ItemControl with a Canvas in the ItemsPanel, just much harder to do especially the layout on resize. BTW, you can define styles for these elements in XAML markup, no need to set up every possible font/brush in C#.

Couple advanced features I often use are IValueConverter interface to translate values or types between views and view models, and DataTemplateSelector to programmatically switch between multiple data templates.

I tend to avoid DataTrigger in XAML, I prefer exposing additional public properties from my view models.

Thank you for your patient and detailed response.

I liked this Pluralsight WPF course a lot, the instructor (Thomas Claudius Huber) is clear in his explanations and seems to be very knowledgeable.

https://www.pluralsight.com/courses/wpf-6-fundamentals

WPF has been superseded (supposedly) by UWP / WinGUI / MAUI / Blazor?

UWP was designed primarily for Windows phones, usability on desktops suffers. And it requires windows store, you can’t just ship an installer .exe

WinUI seems to be copy-pasted from UWP, same usability issues on desktops. Unlike UWP, it’s a mess in terms of software quality. Also the runtime is huge, I think the size in MB even exceeds Electron.

About MAUI, it seems Microsoft decided to make an abstraction over native controls. It’s been tried for decades and it always results in the same suboptimal result because these GUI frameworks implement the least common denominator of available UX. In addition to that, on Windows that thing uses WinUI3 backend, see the previous paragraph.

I don’t know anything about Blazor, but it seems that thing is for web apps?

MAUI is basically Xamarin.Forms, rebranded and rewritten, thus forcing the whole Xamarin community to rewrite their stuff, or go elsewhere.

Miguel de Icaza is pretty sour on this, and quite likely one of the reasons he is now fully into Apple ecosystem and Swift.

Blazor started with being only a WebAssembly based framework, then they decided to put everthing on ASP.NET under Blazor umbrella, and are now pushing Blazor into everything that has a Webview, including the stupid idea of Hybrid Blazor in MAUI, basically Electron in .NET.

Blazor is interesting. They are biting off an absolutely metric done of stuff. I will say their development style -> social media etc seems good which might help drive some buyin. They have public roadmaps. The outcomes still pretty rough ("Could not reconnect to the server") when falling off the happy path. So it still had a bit of that "in theory" development style that in terms of use annoys developers.

Nope, the GUI story is so bad, that at BUILD 2024, WPF was made again an official Windows GUI framework for .NET devs, see BUILD 2024 sessions regarding Windows programming.

Haha.. That is too funny - I haven't been following this closely anymore. It's honestly wild. Does WPF still do data binding by reflection? I can usually "feel" a WPF app if I'm doing a lot of data work.

I remember when WinForms (which I thought was fine!) was killed. Why they just didn't continue to build on that I don't know (yes, I've heard the explanations, the importance of things like having XML (barf) in the framework).

How can you not be absolutely kicking butt on your own platform with a great story especially because they absolutely HAD a great story both at entry level LOB and advanced LOB.

WinForms is still actively developed (although it wasn't always).

I prefer XML to manually placing controls in a window and clicking around a designer GUI at all times. XML is trivially editable by hand, WinForms auto-generated C# isn't.

Supposedly is being worked on for making it more Native AOT friendly.

How we got into this mess? WinDev and DevDiv politcs.

After the Longhorn debacle, its technologies landed on DevDiv, like WCF and WPF.

Sinofsky and friends never were that keen in having .NET coming into their turf, it is no surprise that Hilo sample for Windows 7, then praises COM and C++ for Windows applications[0][1].

Then coming in this path, WinRT came to be, with roots as how .NET was being designed, before Microsoft decided to pivot it as another Java like technology[2].

A bunch of folks in WinDev, weren't happy with C++/CX, so they united to replace it with C++/WinRT, because extensions, when clang and GCC are full of extensions, promised to give back a C++/CX like developer experience in 2017[3], never delivered, went to have fun with Rust/WinRT.

Now C++/WinRT is in maintenance mode[4], and Rust/WinRT never took off, and is now Rust/windows-rs[5].

As paying customer, impacted by those childish attitudes, I would have had the whole team fired.

Finally, check the amount of bugs and complaints on their respective repos,

https://github.com/microsoft/microsoft-ui-xaml https://github.com/microsoft/WindowsAppSDK https://github.com/microsoft/cppwinrt/

And then compare with Project Reunion vision from 2021, and where we are three years later

https://blogs.windows.com/windowsdeveloper/2021/03/29/announ...

Mainly because along the way, as if those changes weren't enough, they also decided to reboot their initial approach with Project Reunion, WinAppSDK took another route, and here we are.

This is only a short overview of how WinRT went down since Windows 8, thus only those that never advocated for it, can honestly suggest WinUI, as they lack the background of how chaotic it all is.

[0] - https://devblogs.microsoft.com/cppblog/announcing-hilo/ [1] - https://learn.microsoft.com/en-us/previous-versions/msdn10/f... [2] - https://arstechnica.com/features/2012/10/windows-8-and-winrt... [3] - https://www.youtube.com/watch?v=7TdpWB_vRZM&t=2983s [4] - https://github.com/microsoft/cppwinrt/issues/1289#issuecomme... [5] - https://github.com/microsoft/windows-rs

This at least explains what from the outside looks like total insanity.

What's been confusing is they've been chasing all sorts of things (phones / tablets / web development) so clearly had money to burn, but couldn't deliver a basic solution for their own platform.

Clean simple line of business apps (ie, datagrid / listviews needs to work etc with bigger excel type datasets) + maybe RemoteApps or some other remoting option for SAAS type deployment would have been a nice option to have for plenty of folks.

For a lot of use cases the modern solutions are both worse to develop for AND are slower / buggier - so you get little for the effort

WPF seems to be one of the preferred native UI platforms:

"Microsoft will refresh WPF with new Windows 11 theming and hyphen-based ligatures support for Microsoft .NET 9 and will continue to invest in WPF as one of the two preferred native user interface platforms on Windows."

The other preferred native UI platform seems to be WinUI 3: "WinUI 3 joins Windows Presentation Foundation (WPF) as the two recommended native UI platforms for developers."

https://news.microsoft.com/build-2024-book-of-news/

I don't know about MAUI / Blazor.

Reply on news.ycombinator.com