Recently, developer Samuel Tulach lamented on his personal blog, "It's so hard to write a GUI application on Windows!" In the article, Samuel Tulach discusses the difficulties of writing GUI applications in C++. He elaborated on several popular libraries, but these libraries often face problems such as dependency management, application size, and styling customization, and there is no perfect solution.
Unexpectedly, this little complaint resonated with many developers, and even appeared on the HN hot list. Next, we will look at what the difficulties are in this article.
For the past few days, Samuel Tulach, a programmer from the Czech Republic, has been looking for a library that will allow him to write programs with a GUI in C++. The requirements he gave were very simple:
- Only Windows needs to be supported;
- commercial use is permitted;
- Easy to design, including support for dark mode;
- The result should be a single .exe file with no or minimal dependencies and no more than 40MB in size;
- It shouldn't take more time to write the GUI part of the program than it does for the actual functionality.
So, Samuel Tulach started to pick out some tools and frameworks, and it turned out that it was not as simple as he thought.
WinUI 3
First, Samuel Tulach started with WinUI 3, a modern user interface (UI) framework designed for Windows application development.
At first glance, it's a good choice. It allows you to use modern Windows components, and you can also customize style colors. For design, you can use XAML, which is very easy to master, or use the Visual Studio designer directly.
WinUI 3 Control Library
Issue: Applications developed using the WinUI 3 framework cannot be distributed unpacked when released. This means that you can't package your application as a single executable file (.exe) with all the dependencies it needs, but instead rely on a specific distribution method, such as packaging as an AppX package or distributing it through the Microsoft Store.
For Samuel Tulach, most of the time, when he tries to migrate an application to a virtual machine or a different machine, it doesn't start properly because of some unknown dependencies missing. To make matters worse, you need to provide a bunch of .dll files that handle WinUI functionality, and there's no way to provide a portable .exe file. There's usually nothing wrong with using packaged forms, but they're installed as AppX packages, which in itself can be problematic (especially if you need access to all the Win32 APIs).
Win32 / MFC / 封装 Win32 的小型库
Immediately afterward, Samuel Tulach turned his attention to Win32. Win32 is an application programming interface (API) that is a core component of Microsoft's Windows operating system. It provides a standard set of interfaces and features for developers to interact with the operating system for creating and managing all aspects of Windows applications, including windows, message handling, file manipulation, network communication, and more.
According to Samuel Tulach, it requires a high degree of portability, so it makes sense to use the operating system's native rendering. Such a program could be a single .exe file (since we have MFC statically linked) and be very small (only a few kilobytes).
At the same time, Samuel Tulach said, the ability to use more minimalist libraries that have already been written by others means that it will be very easy to go from concept to quick implementation of a working application.
Basic Win32 form
Problem: Styling native Win32 controls is a very difficult task. To change the look and feel of these spaces, Samuel Tulach needed to write a dedicated custom draw function for each control, a process that required not only a detailed understanding of the Win32 API's drawing mechanics, but also a significant investment of time and effort.
In response, Samuel Tulach complained, "With this time, I can go directly to support my family." ”
In addition, some of the native Win32 controls used by Windows File Explorer have a dark mode known as "hidden". The user can activate this mode, but it only works for some controls and is not visually ideal or perfect.
Qt
Qt is considered to be an excellent choice for C++ GUI development. Despite its relative complexity, it provides Qt Style Sheets, which make it easy for developers to design and customize the look and feel of the interface. Qt stylesheets use a CSS-like language that allows developers to define the look, layout, and interaction of controls in a familiar way.
OBS studio 使用 Qt 和自定义样式表
The problem, however, is that when using dynamic linking, running a Qt application requires a large number of different .dll files, which together exceed 40MB in size. To reduce the file size, you can choose to statically link Qt to your application, so that the unused parts are removed, reducing the size of your application.
However, Qt is licensed under the LGPL. Under the terms of the LGPL, if you choose to link Qt statically, you must comply with one of the requirements of the LGPL: either the source code of the application is open-sourced, or the object file for recompilation is provided. In addition, Qt offers a commercial license option that can be purchased for a few thousand dollars, exempting you from the obligation to comply with the terms of the LGPL, but this is too costly.
wxWidgets
wxWidgets (https://www.wxwidgets.org/) is a relatively easy library to learn, and wxFormBuilder can also be used. It follows a more permissive license than Qt and can be statically linked to a 3MB executable.
wxWidgets enables an experimental Windows dark mode option
Problem: wxWidgets is a library that uses native Win32 components on Windows. However, wxWidgets doesn't provide the option to easily override draw functions compared to using Win32 or MFC directly, so styling is even more difficult than using Win32 or MFC directly.
Although wxWidgets supports the application of Windows File Explorer's dark mode controls, the actual results are not ideal.
hikogui
hikogui (https://github.com/hikogui/hikogui) is a relatively new retention mode GUI library that uses Vulkan as the backend technology. This means that it harnesses the power of Vulkan for graphics rendering and display. Hikogui has built-in dark mode support, and developers can easily customize and style the interface themselves to suit the needs and design style of the application.
Question: To successfully compile hikogui, a Ph.D. in computer science, particularly expertise in compiler development, may be required. During the experience, Samuel Tulach tried to compile the sample for more than 30 minutes, including trying different code branches and release tags, but ended up with an executable that immediately had access conflicts in a Vulkan library, so he decided to give up.
However, while Samuel Tulach doesn't like to use STL a lot and doesn't even think it's necessary sometimes, he thinks hikogui does look promising.
Scite
Sciter is actually a good alternative to Electron that allows developers to write GUIs for desktop applications using HTML/CSS.
An example of poor anti-aliasing on an SVG icon
Problem: You might think that application size might be an issue, but in reality, the final application size with all the required .dll files is only about 25MB, which is perfectly acceptable to Samuel Tulach.
Samuel Tulach said that it would be better if Sciter could be fully open source, as it would allow developers to use statically linked versions for commercial purposes (same problem as Qt). At the same time, Sciter's standalone license is priced at a much lower price than Qt (currently $310), and Samuel Tulach is willing to pay for it.
However, the main reason for not using this framework right now is that, as you can see in the image above (look at the title bar icon), the rendering is not very good. During the experience, Samuel Tulach revealed that he was experiencing anti-aliasing issues with various fonts and images (with the high-resolution option enabled, even in precompiled scapp.exe). And, no matter what you do, the window will have a fairly thick (2-3 pixels) gray border that is completely impossible to customize or modify.
WinForms / WPF
If you ask a question about writing a GUI library in C++ on Windows, you're likely to get some feedback like "this isn't a good idea", or even a forum expert who will simply suggest that you use a different tech stack to write the front-end part of your application and then load the functionality written in C++ as a component or module.
This makes it easier to customize and stylize the interface and significantly speed up development. From a technical point of view, it is true that a smaller separate executable (.exe) can be generated using a tool like WinForms or WPF.
In detail, there are two ways to do this:
- Package a dynamic link library (.dll files) into your application's resources, and then extract those .dll files from your application's resources into a temporary folder at runtime. Next, use P/Invoke techniques to call these libraries compiled from .dll in a C#/.NET application. This practice allows you to embed functional modules written in C++ as .dll files in your C# or .NET application and dynamically load and invoke them at runtime.
- Use C++/CLI.
Problem: The .NET Framework is pre-installed in Windows 10 and newer, so technically we can still meet the criteria for no dependencies. However, if we choose to package the feature modules written in C++ as .dll files, we still need to extract those .dll files from the packaged resources to a temporary location at runtime and write additional P/Invoke code to call those modules.
Also, if you compile with C++/CLI, the resulting code will be converted to .NET IL code. In other words, the resulting application can be opened in a debugging tool such as dnSpy, and you can see the C++ code translated into the equivalent C# code. In this case, the resulting application is not a purely native code application, but contains a . Intermediate code for the .NET Framework.
And as mentioned at the beginning of the article, Samuel Tulach wants native code, so code based on WinForms or WPF isn't what he really wants.
Solution?
These are just a few of the scenarios Samuel Tulach has considered. After experimenting with different libraries for a long time, and even writing his own MFC style at one point, Samuel Tulach found that there was nothing better for a simple application than Dear ImGui.
Dear ImGui is a lightweight interface development framework for C++, and its main goal is to provide efficient, flexible, and easy-to-use interface development tools. Dear ImGui is a text-based interface development framework that uses simple text commands to create and update user interfaces.
However, Dear ImGui also has some drawbacks when designing complex user interfaces, and it is not a user interface that retains mode, but a user interface in instant mode, so to use it, you must run a GPU renderer like DirectX to render a user interface of 60 frames per second or more.
As shown in the image above, Samuel Tulach has written an example of how to use the built-in multi-viewport feature to make a simple graphical user interface application.
The size of the compiled program is only 500KB, which is very small. This program does not require the installation of any additional dependencies, even if MFC (Microsoft Foundation Classes) is statically linked to the program, and does not require the installation of VC++ (Visual C++) runtime libraries. This makes it very easy to deploy and use the program, and users can execute it without worrying about missing runtime components or dependencies.
Many developers can relate to Samuel Tulach's experience. Netizen pshirshov from HN said:
I've had a similar painful experience. I needed a truly cross-platform (Windows, Linux/Wayland, Mac, iOS, Android) GUI toolkit with a rich library of controls and sensible themes. In fact, the only good option is QT, and it's hard to be efficient with C++ because it still lacks basic features like type destructuring and ADT/GADT with exhaustive checking. QT's binding to other languages is not mature enough.
In addition to QT, there's Avalonia, which is riddled with vulnerabilities. Support for Linux is terrible.
There's also the Kotlin/Compose Multiplatform. It lacks good documentation and advanced controls, and it's still full of bugs.
I can't find any good control libraries for JS/TS, even the paid ones like Telerik and others are pretty messy. So, Electron, Capacitor, React Native - they all believe that even a very basic application requires a lot of effort.
Flutter feels extremely immature, especially since the popularity of the global singleton pattern makes it very difficult to manage even small codebases when using Flutter.
Another user said:
I'm having the same problem with SwiftUI on Mac, and my experience with SwiftUI on Mac is that it still needs a lot of work. The documentation is poor. If you do things in a straightforward way, the performance can be poor. Supporting older versions of the operating system is quite a pain and so on.
Have you ever experienced GUI development at this point? What tools are recommended?
Source:
https://news.ycombinator.com/item?id=40839208
https://tulach.cc/writing-gui-apps-for-windows-is-painful/