C++, like Python and many other programming languages,* does not come with a built-in graphical front end. It wasn't until the mid-1980s that PC operating systems developed those sorts of user interfaces, and even after Windows and Apple’s various operating systems became the norm, event-driven programming took a few additional years to catch up. Thirty years ago, all I/O was done on character displays. It wasn’t until the early ‘90s that graphical toolkits first appeared. Since then, Mac OS (and to a lesser extent, Linux) have since grown in importance compared to Windows, making it a better investment to create software that can run on all three platforms without requiring a rewrite. Without cross-platform toolkits, you would need to do a substantial rewrite for any other platform just to handle the I/O and user interaction. Meanwhile, graphics on each operating system are done in completely different ways. Cross-platform toolkits shield you (somewhat) from those variations and oddities. You may never need to port your Windows application to Mac or Linux, but at least you know you can. In this list, I’ll look at five cross-platform GUI toolkits that are programmed in C++, and are still under active development. The five I’ve chosen are Qt, wxWidgets, JUCE, CEGUI, and CEF (some others—particularly GTK, MFC, and Cocoa—didn’t make the list as they’re not fully cross-platform).
Qt, one of the earlier frameworks, is now 21 years old. Previously owned by Nokia, the current owner is the Finland-based Qt Company. The platform is licensed as free/open source, and available in Indie Mobile, Professional and Enterprise versions starting at $79 per month. This older framework has reinvented itself with its latest incarnation, Qt 5, which is used in everything from mobile apps to
automobiles and
medical devices. One of its big strengths is the windowing system, which lets you create user interfaces, and includes advanced features such as displaying charts, data visualizations and maps from third-party providers. Qt Version 5 now handles touch as well as mouse and keyboard handling, and you can add virtual keyboards on X11 and Windows. On KDE Linux, Qt is the native GUI library, so if you are developing for KDE platforms, then you should consider Qt.
Developer Julian Smart created wxWidgets 24 years ago (making it even older than Qt!) and remains a core developer. It’s similar in many ways to Qt, although some developers prefer it because it uses native SDKs (i.e., Windows built-in routines on Windows, Mac routines on Mac for drawing graphics). These make applications look more native; on Windows, for instance, it will use Windows graphics. (Qt, by comparison, draws its own widgets on each platform, though tries to look as close as possible to the platform by using some low level code for drawing scrollbars and buttons.)
This open-source cross-platform library uses a similar license to Qt. It focuses on cross-platform audio, interactive, embedded or graphic applications. Originally developed by British developer Jules Storer, it was acquired by Raw Material Software, a company that develops audio products. As a result, JUCE has a large amount of audio functionality, because it was originally designed for building audio applications. The JUCE library also includes many user-interface elements, graphics, audio, XML and JSON parsing, networking, cryptography, multi-threading, and an integrated interpreter that mimics ECMAScript's syntax. This reduces or eliminates the need for third-party libraries and the dependency issues that those can cause. Nothing is more frustrating than an update to a third-party toolkit that breaks the build. JUCE also includes the "introjucer,” an IDE tool that can generate Xcode projects, Visual Studio projects, Linux Makefiles, Android Ant builds and CodeBlocks projects.
Crazy Eddie's GUI has been in development since 2003 and should easily make version 1.0 by 2020, as it's currently at 0.87. Like the others here, it works on Windows, Mac and Linux and supports 64- as well as 32-bit. Unlike the rest of the cross-platform GUIs here, the focus is on games development; but that said, it provides the developer a bunch of Widgets (buttons, Combo etc.), so you aren’t restricted to just games applications. Most games require a GUI for all the menus and configuration screens that render on platforms such as DirectX or OpenGL. These are skinnable, allowing customization to match your game's aesthetics. CEGUI Configuration also makes extensive use of XML files. These are not just for configuring the skins (i.e., how the controls look, common color scheme etc.), but everything else such as animation, images, layouts and scheme to control game data files. All of these rely on XML.
The Chromium Embedded Framework is a simple framework for embedding Chromium-based browsers in other applications. This makes it different from the other C++ libraries here, which are for creating standalone applications. You might not have heard of it, but according to the
documentation, there are over 100 million installed instances of CEF embedded in many products. It's now eight years old and up to version 3. The integration into your Chrome browser allows access to JavaScript, GPU acceleration via WebGL, even rendering into off-screen memory and, soon, access to speech input.
Conclusion
Although these are all programmed in C++, there are many language bindings available, so it's worth checking what programming languages you can use them with. wxWidgets is particularly good in this respect, as is Qt, which is used in several specialist operating systems and automobile software. Qt seems more popular in enterprises, presumably because of the paid support, whereas scientists and Indy developers tend to favour wxWidgets because it's free and matches Qt. Both Qt and wxWidgets cover a lot of similar territory, and it’s probably a case of which you prefer (or, if Qt, which version you can afford). Producing commercial applications with Qt will cost, so you may prefer wxWidgets. Both frameworks have plenty of third-party tools to simplify development. I included CEF because including a browser in your desktop application can come in handy, perhaps for showing online documentation, displaying a link to news, or showing an update download. Likewise, having once
written a simple graphical GUI (in C) for a game a few years back, I appreciate the effort that's gone into a comprehensive one like Crazy Eddie’s GUI.
*An earlier version of this article incorrectly suggested that Java did not have a GUI at some point in its existence.
