14.1 Desktop Components
Linux desktop configurations offer a great deal of flexibility. Most of what the Linux user experiences (the “look and feel” of the desktop) comes from applications or building blocks of applications. If you don’t like a particular application, you can usually find an alternative. And if what you’re looking for doesn’t exist, you can write it yourself. Linux developers tend to have a wide variety of preferences for how a desktop should act, which makes for a lot of choices.
In order to work together, all applications need to have something in common. At the time of this writing, the core of the Linux desktop is in a transitional state. From the beginning until recently, Linux desktops used X (X Window System, also known as Xorg, after its maintaining organization). However, this is now changing; many distributions have transitioned to a software set based on the Wayland protocol to build a windowing system.
To understand what’s driving this change in the underlying technology, let’s take a step back and look at a few graphics basics.
14.1.1 Framebuffers
At the bottom of any graphical display mechanism is the framebuffer, a chunk of memory that the graphics hardware reads and transmits to the screen for display. A few individual bytes in the framebuffer represent each pixel of the display, so the idea is that if you want to change the way something looks, you need to write new values to the framebuffer memory.
One problem that a windowing system must solve is how to manage writing to the framebuffer. On any contemporary system, windows (or sets of windows) belong to individual processes, doing all of their graphics updates independently. So if the user is allowed to move windows around and overlap some on top of others, how does an application know where to draw its graphics, and how do you make sure that one application isn’t allowed to overwrite the graphics of other windows?
14.1.2 The X Window System
The approach that the X Window System takes is to have a server (called the X server) that acts as a sort of “kernel” of the desktop to manage everything from rendering windows to configuring displays to handling input from devices, such as keyboards and mice. The X server doesn’t dictate the way anything should act or appear. Instead, X client programs handle the p. 349 user interface. Basic X client applications, such as terminal windows and web browsers, make connections to the X server and ask to draw windows. In response, the X server figures out where to place the windows and where to render client graphics, and it takes a certain amount of responsibility for rendering graphics to the framebuffer. The X server also channels input to a client when appropriate.
Because it acts as an intermediary for everything, the X server can be a significant bottleneck. In addition, it includes a lot of functionality that’s no longer used, and it’s also quite old, dating back to the 1980s. Somehow, it has been flexible enough to accommodate many new features that have extended its lifespan. We’ll describe the basics of how to interact with the X Window System later in this chapter.
14.1.3 Wayland
Unlike X, Wayland is significantly decentralized by design. There’s no large display server managing the framebuffer for a number of graphical clients, and there’s no centralized authority for rendering graphics. Instead, each client gets its own memory buffer (think of this as sort of a sub-framebuffer) for its own window, and a piece of software called a compositor combines all of the clients’ buffers into the necessary form for copying to the screen’s framebuffer. Because there is normally hardware support for this task, the compositor can be quite efficient.
In some ways, the graphics model in Wayland isn’t too different from the practice that most X clients have been performing for years. Instead of getting any assistance from the X server, most clients render all of their own data as a bitmap and then send the bitmap to the X server. To acknowledge this somewhat, X has a compositing extension that has been in use for several years now.
For the task of channeling input to the correct application, most Wayland setups and many X servers use a library called libinput to standardize events to clients. This library is not required by the Wayland protocol, but on desktop systems, it’s nearly universal. We’ll discuss libinput in Section 14.3.2.
14.1.4 Window Managers
A major difference between X and Wayland systems is in the window manager, the piece of software that determines how to arrange windows on the screen and is central to the user experience. In X, the window manager is a client that acts as a helper to the server; it draws the windows’ decorations (such as title bars and close buttons), handles input events to those decorations, and tells the server where to move windows.
However, in Wayland, the window manager is the server, more or less. It is responsible for compositing all of the client window buffers into the display framebuffer, and it handles the channeling of input device events. As a result, it is required to do more work than a window manager in X, but much of that code can be common between window manager implementations.
Many window manager implementations exist in both systems, but X has far more by virtue of its longevity. However, most of the popular window managers, such as Mutter (in GNOME) and Kwin (from KDE) have also been extended to include Wayland compositing support. Regardless of the underlying technology, it’s not likely that there will ever be a standard Linux window manager; because user tastes and requirements are diverse and constantly changing, new window managers appear all the time.
14.1.5 Toolkits
Desktop applications include certain common elements, such as buttons and menus, called widgets. To speed up development and provide a common look, programmers use graphical toolkits to provide those elements. On operating systems like Windows or macOS, the vendor provides a common toolkit, and most programmers use that. On Linux, the GTK+ toolkit is one of the most common, but you’ll also frequently see widgets built on the Qt framework and others.
Toolkits usually consist of shared libraries and support files, such as images and theme information.
14.1.6 Desktop Environments
Although toolkits provide the user with a uniform outward appearance, some details of a desktop require a degree of cooperation between different applications. For example, one application may wish to share data with another or update a common notification bar on a desktop. To provide for those needs, toolkits and other libraries are bundled into larger packages called desktop environments. GNOME, KDE, and Xfce are some common Linux desktop environments.
Toolkits are at the core of most desktop environments, but to create a unified desktop, environments must also include numerous support files, such as icons and configurations, that make up themes. All of this is bound together with documents that describe design conventions, such as how application menus and titles should appear and how applications should react to certain system events.
14.1.7 Applications
At the top of the desktop are applications, such as web browsers and the terminal window. X applications can range from crude (such as the ancient xclock program) to complex (such as the Chrome web browser and LibreOffice suite). These applications normally stand alone, but they often use interprocess communication to become aware of pertinent events. For example, an application can express interest when you attach a new storage device or when you receive new email or an instant message. This communication usually occurs over D-Bus, described in Section 14.5.