Options for cross-platform native toolkits
As indicated earlier in this chapter, the idea of a cross-platform toolkit is not new—in fact, they date back to the mid-1990s, barely 10 years into the history of GUI development. It is important to understand that even among native cross-platform toolkits there are distinct approaches with different benefits and drawbacks.
Visual style
Cross-platform toolkits can be divided into two distinct visual approaches—the desire to match the look and feel of the system at runtime versus the delivery of a distinct look that will be consistent across all the environments. The Qt and GTK+ toolkits began with their own visual style that added the ability to be controlled by visual themes. Over time, they developed operating system-specific themes that allowed them to match the design of other applications on a system. In contrast, the Java AWT library was created as a code-level abstraction, meaning that programs would use operating system widgets to render despite the application being written for no specific platform. Interestingly, in 1998, Sun (the creators of Java) introduced the Swing toolkit, which offered a whole new look and feel that would be consistent across all platforms. This replacement user interface library slowly gained popularity as AWT was phased out. In an interesting twist, Sun introduced operating system lookalike themes that a developer could choose to enable in their app (unlike in GTK+ and Qt, this was not a user preference).
Compiled versus interpreted
The other factor that commonly defines a toolkit is the choice of programming language—these can be split between those that are compiled into an application binary versus those distributed as source code that is interpreted at runtime. This distinction commonly correlates with statically typed languages compared to dynamically typed languages, which impacts programming styles and the design of associated APIs. In a compiled language that uses static typing, all variables are defined and checked at compile time. Their types (that is, the sort of content they contain or refer to) are set in the definition and never change. This approach typically catches programming errors early and can lead to robust code, but can be criticized as leading to slower application development. A compiled application will usually work directly on the computer it is built for, meaning that it does not require the installation of supporting technologies alongside the application. To achieve this, however, the apps will typically need to be compiled for each supported platform—again leading to longer development times required, this time for distribution tasks.
In comparison, an interpreted language is typically held up as supporting faster development and quicker delivery. By allowing variables to be used for different types of content, the source code of an application can be shorter with fewer complications during the programming phase. Conversely, the reduced rigor means that it is usually required to have a more solid test infrastructure (through unit tests or automated user interface testing) that can ensure the correctness of the software. Distributing apps in this way will require a runtime environment to be installed so that the code can be executed (like the embedded web browser we saw when discussing hybrid apps). For some operating systems, there may be interpreters installed already, and for others, they may have to be installed by the user. Interestingly, there are some compilers available for interpreted languages that allow them to be distributed like any other binary application, though with the preceding trade-off that applications must be built for each target platform individually.
Interpreted options
Due to the popularity of building GUIs, each of the main interpreted languages has its preferred toolkit. The Java runtime includes its own graphics routines, which means it can include a bespoke user interface, namely Swing. More recently, the JavaFX library has been built on top of the same graphical code. As mentioned earlier, Java also includes the AWT library, which delegates to system components.
Other popular programming language runtimes do not ship with the same graphical components and so they typically rely on an underlying library. TkInter is the standard GUI library for Python, based on the Tk library, while the Ruby language does not recommend a standard library. Language bindings, which allow programmers to create applications using an interpreted language while using an underlying existing widget toolkit, such as Tk, GTK+, or Qt, are very popular. Using this method, there are too many options available to list, but they usually have the same drawback of not being designed for the language and so can be less intuitive to program than options built specifically for the language being used.
Compiled options (C-based)
As shown earlier in this chapter, GUI development has a long history and the most popular toolkits were initially designed many years ago. GTK+ and Qt are both exceptionally popular, but they were designed for the C and C++ languages, respectively. While this does not stop them from being effective choices, it can make them seem a little outdated to the modern programmer. Possibly due in part to this reason, these GUI frameworks have seen language bindings made available for almost every programming language that exists. However, this does mean that you need to know a little about how the underlying system works to be most effective in development. For example, memory management in a C library is a complex and manual task, and not one that most developers want to worry about. Additionally, a C++-based library will have a different threading model beneath the surface that may not interact well with the higher-level language methodologies.
An additional consideration for toolkits that were designed decades ago is that they may not be best suited for the modern landscape of graphical computing devices. Screens, whether on a desktop, laptop, or mobile device, now come in a wide variety of sizes and pixel densities. This can bring challenges if code was built assuming that a pixel is a certain size, as used to be true. 96 dots per inch (DPI) was a common assumption, meaning that something 96 pixels high would measure about an inch when displayed. However, based on current devices, it could be anywhere from an inch down to 3/16ths of an inch (only 20% of the intended size), so it is important to understand how this will impact your application design. Older toolkits are typically based on pixel measurements, where the display is simplified to be a certain number of pixels (1, 2, 3, or 4) to represent each source pixel's size (which would be 1, 4, 9, or 16 pixels to display a square). Using a toolkit that scales in this manner can result in pixelated output if the application does not adapt carefully to the device.
Compiled options (other languages)
In part due to the legacy of the older C/C++-based GUI toolkits, but also in part because new programming languages bring benefits over the old ones, most of the newer compiled languages also have a toolkit built alongside. These more modern toolkits typically handle today's variety of devices much more effectively due to their more recent design. The challenges with pixel- or bitmap-based design is being overcome by moving to a vector image-based design. Vector images can be displayed at a higher quality output on screens of any pixel density. They do this by defining image elements such as lines, rectangles, and curves independently of output pixels; they are only drawn after the number of pixels available has been determined, resulting in higher quality on most output devices.
As we saw earlier, an operating system manufacturer often dictates the programming language used, and can push for new versions or programming languages when required. We can see this with Apple's recent move to Swift for the latest version of their UIKit and AppKit frameworks (this language is intended primarily for Apple devices but the trend is still noteworthy). Microsoft's development platform is currently geared toward C#, having previously used C, C++, and Visual Basic. Google is putting its energy into the Dart programming language and the Flutter toolkit built on top.
Other languages, such as Go, do not have an official GUI toolkit or widget library. In these situations, we can see various projects emerge with different ways of addressing the gap. In Go, the most active projects are andlabs UI, Fyne, and Gio. The andlabs project aims to use the current system style—in fact, it wraps the code to display them with a simple Go API—much like Java AWT discussed earlier. Gio is an immediate-mode GUI toolkit that aims to provide as much control as possible to the application developer, requiring the app to manage the rendering and event processing. The Fyne project aims for an API that is simple to learn and extend, without needing to worry about the rendering process—this is commonly known as retained mode as the widget state is managed by the library.
