-
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. 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 <-> std::vector or std::iterator 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 beetween return types (HRESULT vs bool), having to declare same interfaces both in C++ and C#, ...
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
Windows UI Library
Windows UI Library: the latest Windows 10 native controls and Fluent styles for your applications
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
-
slint
Slint is a declarative GUI toolkit to build native user interfaces for Rust, C++, or JavaScript apps.
I'm working on a GUI toolkit that should match the requirements: Slint - https://slint.dev
-
As of Sciter and "antialiasing" issues mentioned in the article...
Author did not enable high-DPI support in his/her application.
Either in Visual Studio : https://sciter.com/wp-content/uploads/2024/06/high-dpi-aware...
Or by including proper manifest: https://gitlab.com/sciter-engine/sciter-js-sdk/-/blob/main/d...
-
It's even worse.
> Those were only a few options that I considered. After a very long time trying out all sorts of different libraries and at one point even writing my own MFC styles, I figured out that for simple apps there is simply nothing better suited than Dear ImGui.
They decided to go with the option that deviates the most from the standard Windows UI because there are no native controls at all and it's a nightmare for accessibility (see https://github.com/ocornut/imgui/issues/4122). I use it for prototyping privately, but I'd never make anything I want to release into the world with it.
-
Apps developed for the modern (open-source) version of .NET may be compiled to a native code (NativeAOT). Some time ago, I tried AOT on a simple WinForms project and it worked. Unfortunately, functions using COM APIs are not yet supported (as they rely on reflection). There is an ongoing effort to fix this problem: https://github.com/dotnet/winforms/issues/4649
-
go-sciter
Golang bindings of Sciter: the Embeddable HTML/CSS/script engine for modern UI development (by AdguardTeam)
1. These wrappers are Open Source.
2. I do not have customers that requested either one of these wrappers.
3. Customers that do use one of wrappers, as AdGuard for example, maintain their own version of Sciter/Go: https://github.com/AdguardTeam/go-sciter
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
-
I've used FLTK for an application. It relies heavily on opaque pointers and convention. The compiler will not help you out if you mess up.
https://github.com/gammasoft71/Examples_FLTK/blob/c6f630eaa3...
-
ProjectReunion
The Windows App SDK empowers all Windows desktop apps with modern Windows UI, APIs, and platform features, including back-compat support, shipped via NuGet.
-
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/
-
-
There is also furnace[0] and mmlgui[1]. Which are recently developed programs that people have been using to create chiptune and music for retro video game consoles. Including being used by Yuzo Koshiro.
[0] https://github.com/tildearrow/furnace
-
-
Tauri[0] is another HTML/CSS/JS-converter that generates small binaries by relying on the presence of WebView. Works pretty well.
[0] https://tauri.app
-
-
I've been eyeing https://neutralino.js.org/ since if I'm going to make the app render right on browsers then relying on the same code via webviews likely isn't (much) more portability effort.
-
-
I have a reasonably complete implementation of dark mode in my open source application, Explorer++. It uses the standard Win32 controls and applies a variety of strategies to get something that looks more-or-less coherent when dark mode is enabled. ThemeManager.cpp[0] contains the bulk of the functionality. It could be useful as a reference for how you might create a dark version of a standard Win32 control.
[0] https://github.com/derceg/explorerplusplus/blob/4bad3ab95d87...
-
> 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 ComLightLib.
C# interface: https://github.com/Const-me/Cgml/blob/master/CGML/CgmlNet/iC...
-
This can be solved by hooking system dll, see my project: https://github.com/ysc3839/SingleExeXamlIsland
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
