In the previous article, I organized a configuration for using both a local GUI and a remote GUI in a Debian-based GNU/Linux environment, and examined phenomena that commonly appear when using xrdp, such as a black screen or an immediate disconnect after login, from the standpoint of Linux GUI session structure. The important point established there was that xrdp is better understood not as a mechanism that simply shares an existing local screen as-is, but as a mechanism in which xrdp-sesman authenticates the user, launches an appropriate X server, and starts a GUI session. That understanding is closer to how it actually works [1].
Once that premise is accepted, using a local GUI and a remote GUI simultaneously with the same user account is no longer a simple matter of “having two screens.” In Linux desktop environments, a session bus is created for each login, and inter-process communication assumes that bus. In addition, systemd-logind and pam_systemd manage login sessions and the user runtime directory, thereby forming user-space state tied to each login [2][3][4]. For that reason, stable remote GUI operation depends not only on how lightweight a desktop environment is, but also on how understandable its configuration structure and session structure are.
Seen from that perspective, Xfce is not valuable merely because it is a lightweight desktop environment. Its essential advantage is that its configuration management structure is comparatively transparent, and that its functions are sufficiently separated to make the system easier to understand. In practice, Xfce settings are managed through a configuration system called xfconf, while their concrete state is stored as configuration files under the user’s home directory [5][6].
However, a different problem appears when Xfce is used in actual operations. The GUI makes it easy to change settings, but it is not immediately obvious which file receives each change, how far those settings can be migrated safely, and from what point onward hardware or environment dependency becomes significant. This is especially important when the same settings need to be reproduced across multiple machines, or when the environment is managed as dotfiles. In that case, the structure has to be organized explicitly in advance.
Accordingly, this article first confirms how Xfce stores its settings, then systematically organizes the main configuration files and their roles, the settings that matter most in real operations, and the points that require attention when migrating an environment.
1. How Xfce stores its settings
The first point to establish when understanding Xfce settings is that Xfce is not merely a set of XML configuration files. It is built around a configuration system called xfconf. xfconf is a hierarchical settings system that adopts a structure with channels at the top level and properties beneath them [5]. For example, panels are handled under the xfce4-panel channel, the window manager under xfwm4, and the desktop under xfce4-desktop. Each of these is treated as an independent configuration unit.
At the same time, the concrete settings that users can actually inspect are usually stored as XML files under ~/.config/xfce4/xfconf/xfce-perchannel-xml/. This arrangement also aligns with the XDG Base Directory Specification, which recommends storing application configuration under ~/.config [7]. Therefore, when examining Xfce settings, it is necessary to distinguish clearly between xfconf as the configuration system and the XML files in which its resulting values are stored.
1 2 3 4 5 6 7 8 9 | ~/.config/xfce4 ├─ xfconf │ └─ xfce-perchannel-xml │ ├─ xsettings.xml │ ├─ xfce4-panel.xml │ ├─ xfce4-keyboard-shortcuts.xml │ ├─ xfce4-power-manager.xml │ ├─ xfwm4.xml │ └─ xfce4-desktop.xml |
The important caution here is that seeing this directory does not mean the entirety of Xfce’s effective configuration has been captured without remainder. Many user settings are indeed stored there, but xfconf also has default values and a kiosk mode mechanism, so the XML visible to the user does not always represent the full set of effective values [5]. In practice, it is more accurate to regard this as the main location where a large portion of user settings can be observed.
With that framing, Xfce settings can be understood as a three-layer structure: xfconf as the infrastructure that manages the whole configuration space, channels as the logical groups divided by function, and XML files as the concrete storage form of user settings. One reason Xfce configuration management is comparatively easy to understand is that these three layers are exposed in a way that humans can trace directly.
| Layer | Role | Example |
|---|---|---|
| Configuration system | The foundation that manages Xfce settings as a whole and handles reading, writing, and notification of values. | xfconf |
| Configuration channel | A logical group that divides settings by function and serves as the main unit of classification. | xfce4-panel, xfwm4, xsettings |
| Configuration file | The main storage form of user settings and the practical target for backup or migration. | xfce4-panel.xml, xfwm4.xml, xsettings.xml |
2. Main configuration files
Xfce settings are split into channels by function, and their main user-visible portion is saved as XML files. The advantage of this structure is that the role of each setting can be understood in functional units. Appearance, panels, shortcuts, window management, the desktop, and power management all appear in forms that map fairly directly to configuration files [5][6].
In many Xfce environments, the following six files form the practical core of the user configuration. Because they directly affect day-to-day operation, appearance, layout, and power behavior, they are the most important starting point for understanding Xfce configuration.
| File name | Managed area | Main content |
|---|---|---|
| xsettings.xml | GTK appearance settings | Stores settings that affect the overall appearance of GTK applications, including themes, fonts, icon themes, and cursor themes. |
| xfce4-keyboard-shortcuts.xml | Keyboard operation | Manages shortcut bindings such as application launch keys, window operations, and workspace switching. |
| xfce4-panel.xml | Panel | Holds the main structure of the panel, including the number of panels, their position, size, display mode, and plugin composition. |
| xfce4-power-manager.xml | Power management | Defines behavior related to display power-off, suspend, power button actions, and battery-related operation. |
| xfwm4.xml | Window manager | Stores window management settings such as focus behavior, decorations, workspace count, and title bar behavior. |
| xfce4-desktop.xml | Desktop | Manages desktop display settings such as wallpaper, desktop icons, and background presentation. |
This list shows that Xfce separates settings in units that are easy for humans to understand by meaning. In GNOME-family environments, GSettings and dconf occupy the center of configuration management, with dconf acting as a backend. In Xfce, by contrast, the location of settings can often be traced directly as files [8][9]. That is not a trivial implementation difference. It has direct consequences for how understandable the environment remains over long-term operation.
3. The role of each configuration file
A plain list of file names still leaves the actual mapping between user actions and saved state somewhat abstract. This section therefore organizes what kinds of settings are stored in each of the six main files and in what operational situations they matter most. The clearer this mapping is, the easier environment migration and dotfiles management become.
3.1 xsettings.xml
xsettings.xml is the central file for appearance. In Xfce’s Appearance settings, themes, icon themes, fonts, and related items can be changed, and those choices are ultimately stored as values in the appearance channel [10]. When the goal is to reproduce the visual appearance of an environment, this file is one of the most important targets.
| Main setting item | Meaning |
|---|---|
| ThemeName | Specifies the GTK theme and determines the overall appearance of widgets. |
| IconThemeName | Specifies the icon theme and affects the look of file managers, menus, and similar interfaces. |
| FontName | Specifies the default font used by GTK applications. |
| CursorThemeName | Specifies the cursor theme and controls pointer appearance. |
3.2 xfce4-keyboard-shortcuts.xml
xfce4-keyboard-shortcuts.xml supports the user’s operation scheme. In Keyboard settings, shortcuts can be added or changed, and key combinations can be assigned to application launch, window operations, and other actions [11]. In environments where operational habits are deliberately fixed, losing this file produces a large subjective change in usability.
| Main setting item | Meaning |
|---|---|
| commands | Defines the command to launch for an arbitrary key combination. |
| xfwm4 | Stores operation keys for window movement, maximization, workspace movement, and related window actions. |
3.3 xfce4-panel.xml
xfce4-panel.xml is the file that manages the structural skeleton of the panel. In Panel Preferences, the panel position, length, display mode, monitor assignment, and item composition can be modified [12]. For that reason, when reproducing a UI layout, this file becomes a central management target.
However, this is also the most important point of caution. The official Xfce Panel documentation makes it clear that panel behavior is affected not only by the GUI itself but also by hidden Xfconf settings and GTK-side configuration [13]. In addition, the existence of a dedicated tool called panel profiles, which supports layout backup, restoration, import, and export, shows that panel reproduction should not be assumed to be fully solved by xfce4-panel.xml alone [14]. In practice, plugin-related files under ~/.config/xfce4/panel/ and theme-side settings may also be involved.
| Main setting item | Meaning |
|---|---|
| panels | Defines the overall framework, including the number of panels, their position, size, and display mode. |
| plugins | Manages which plugins are placed on the panel. |
| launchers | Provides the starting point for settings associated with launcher composition. |
3.4 xfce4-power-manager.xml
xfce4-power-manager.xml is particularly important on notebook PCs and in energy-conscious operation. Power Manager handles settings such as display power-off, suspend, power-button behavior, and battery state handling [15]. Even among user settings, this file is strongly affected by differences in hardware.
| Main setting item | Meaning |
|---|---|
| dpms | Stores display power management behavior. |
| sleep-mode | Defines the policy for suspend or hibernation behavior. |
| button actions | Manages the response to the power button and lid-open or lid-close events. |
3.5 xfwm4.xml
xfwm4.xml stores the behavior of window management. Xfwm4 is Xfce’s window manager, and it holds settings directly tied to daily operation, such as decorations, focus behavior, and workspace handling [16]. This file tends to affect operational feel more than visual appearance alone.
| Main setting item | Meaning |
|---|---|
| workspace_count | Defines the number of workspaces. |
| focus_mode | Specifies the focus policy, such as click-to-focus. |
| theme | Manages the window decoration theme. |
3.6 xfce4-desktop.xml
xfce4-desktop.xml is responsible for wallpaper and the desktop area itself. In Desktop settings, wallpaper, icons, and background presentation are managed [17]. It is important for appearance reproduction, but it also contains items such as wallpaper paths that may break more easily across different environments.
| Main setting item | Meaning |
|---|---|
| image-path | Defines the file path of the image used as wallpaper. |
| icons | Manages whether desktop icons are shown and how they are handled. |
| backdrop settings | Stores background rendering mode and per-workspace background behavior. |
4. What matters most in practice
Understanding Xfce configuration does not mean every file must be managed with equal weight in actual operations. The important distinction is which files define the character of a user environment most strongly, and which files are more likely to break because they depend heavily on the surrounding environment. Without that distinction, dotfiles management becomes unnecessarily bloated and migration accidents become more common.
The highest-priority targets are generally xsettings.xml and xfce4-keyboard-shortcuts.xml. The former stores appearance, and the latter stores the operational scheme. Together they have the greatest impact on how familiar or unfamiliar a migrated environment feels. Next comes xfwm4.xml, because workspace count and focus policy affect the user’s working style. By contrast, xfce4-panel.xml is important but cannot always be copied blindly because of monitor configuration and plugin dependency. xfce4-power-manager.xml depends even more strongly on hardware, so its values may not be appropriate on a different machine.
| Configuration file | Managed area | Priority | Reason |
|---|---|---|---|
| xsettings.xml | Appearance | High | Theme, font, and icon changes alter the overall impression of the environment significantly. |
| xfce4-keyboard-shortcuts.xml | Operation scheme | High | It reflects the user’s daily habits, so losing it affects practical working efficiency directly. |
| xfwm4.xml | Window management | Medium | It affects working style, but its loss is usually less disruptive than losing appearance or shortcut settings. |
| xfce4-panel.xml | Panel layout | Medium | It is important, but is more easily affected by resolution, monitor count, plugins, and related files. |
| xfce4-power-manager.xml | Power management | Lower | Optimal values vary widely depending on hardware conditions such as notebook or desktop use and external power status. |
Once the structure is organized this way, it becomes clear that Xfce settings are better managed by priority rather than by the vague principle of “save everything.” In shared multi-machine use especially, treating appearance and operation scheme as the first-class portable settings, while adjusting panel and power behavior according to environment differences, usually leads to more stable results.
5. How to inspect and change settings
There are broadly three ways to handle Xfce settings: through the GUI settings tools, through xfconf-query for logical inspection of settings, and through direct management of XML files [6][18]. These should not be regarded as mutually exclusive methods. They are better understood as different tools with different operational roles.
For day-to-day setting changes, using the GUI is the natural approach. Xfce Settings Manager centralizes entry points to the various configuration dialogs and allows visual changes to appearance, input, desktop behavior, power behavior, and more [6]. By contrast, when it is necessary to inspect which key holds which value, xfconf-query is highly effective. It can display and modify values stored in Xfconf from the command line, which makes it suitable for inspection, scripting, and reproducible management [18].
For example, the following commands can be used to inspect the available channels or the current values in a specific channel.
1 2 3 4 5 | # List all Xfce configuration channels xfconf-query -l # Show all properties of the panel configuration xfconf-query -c xfce4-panel -lv |
On the other hand, from the standpoint of backup and migration, direct file management is effective. A practical division of labor is therefore: GUI tools for routine changes, xfconf-query for inspecting the logical structure and current values, and XML files for preserving the concrete state of the environment.
| Method | Characteristic | Main use |
|---|---|---|
| GUI settings tools | Allow visual changes and are suitable for ordinary daily configuration work. | Routine changes, experimentation, and screen-oriented adjustment |
| xfconf-query | Allows CLI inspection of configuration keys and is strong at showing current values. | Investigation, automation, difference checking, and scripting |
| XML file management | Preserves the main concrete state of the environment at the file level. | Backup, migration, and version control |
6. Backup and migration strategy
The key point in migrating Xfce settings is not simply to copy ~/.config/xfce4 wholesale. Full backup is certainly possible and is the simplest approach. In practice, however, migration becomes more stable when the portable settings and the environment-sensitive settings are distinguished in advance.
Appearance settings and keyboard shortcuts are generally safe to migrate. Panel settings, by contrast, can change their appearance depending on monitor count and resolution. Power management is even more sensitive, because notebook and desktop systems differ greatly, and even two notebook PCs may behave differently because of firmware or power management daemon differences. The practical principle, therefore, is to separate settings that can be copied safely from settings that should be reconsidered on the target machine.
A full backup itself can be created as follows.
1 | tar czf xfce-settings-backup.tar.gz ~/.config/xfce4 |
Even so, while this is a valid preservation method, it is not always the best method for full restoration. On a new system, a safer workflow is usually to restore xsettings.xml and xfce4-keyboard-shortcuts.xml first, then add xfwm4.xml if needed, and only after that inspect the panel and power configuration separately.
| Migration target | Relevant file | Migration suitability | Caution |
|---|---|---|---|
| Appearance | xsettings.xml | High | Exact reproduction is impossible if the target system lacks the required fonts or themes. |
| Shortcuts | xfce4-keyboard-shortcuts.xml | High | The invoked commands and paths must still be valid on the target system. |
| Window management | xfwm4.xml | Medium | Usually portable, but theme differences and display differences may alter details. |
| Panel layout | xfce4-panel.xml and related files | Environment-dependent | Monitor topology, plugin differences, and missing related files may break the result. |
| Power management | xfce4-power-manager.xml | Low | Because it depends heavily on machine-specific power behavior, treating it as reconfiguration territory is often safer. |
7. The design philosophy behind Xfce’s configuration structure
What becomes clear from the discussion above is that Xfce is useful not simply because it is “old-fashioned and lightweight,” but because its configuration responsibilities are separated in a way that remains understandable to the operator. xfconf divides settings into channels, and the main user-visible state can be traced through XML files under the home directory [5][6]. That transparency makes Xfce well suited to long-term operation and dotfiles-based management.
This characteristic becomes easier to grasp when compared with the configuration style of the GNOME family. GSettings is a configuration API, and dconf is its representative backend [8][9]. GNOME also has a logically organized configuration system, but the user experience is different from Xfce’s comparatively direct file-level traceability of the main settings. The point is not to declare one universally superior. It is that Xfce more often allows an operator to trace concretely where each setting lives and what it affects.
| Viewpoint | Xfce | GNOME family |
|---|---|---|
| Central configuration concept | xfconf channels and XML files | GSettings with a dconf backend |
| Traceability of major user settings | Easy to trace as files | Easy to trace as keys, but the storage form is less directly visible |
| Operational impression over the long term | Easy to identify the location of settings and migrate them selectively | Strong logical organization, but less suitable for workflows that want to touch the concrete storage form directly |
In that sense, choosing Xfce for remote GUI operation or multi-machine use is not only a matter of “lightness.” A major practical benefit is that the boundaries between settings and responsibilities remain visible enough that, when something breaks, a human can often make a reasonable guess about which layer should be inspected first.
8. Comparing Xfce with GNOME Flashback
Once Xfce’s configuration structure has been organized this far, the next natural question is how it differs from GNOME Flashback. Both are desktop environments widely available on GNU/Linux and both are often regarded as relatively lightweight choices, but their design philosophies differ substantially. Xfce is a simple environment built from relatively independent components whose settings and roles are easy to trace. GNOME Flashback, by contrast, may look visually classical and comparatively light, but structurally it is still built on GNOME-family session management, configuration infrastructure, and related services. For that reason, comparing them only by “which one is lighter” is less accurate than comparing them by structure, configuration management, ease of failure analysis, and long-term operability.
Once the Xfce settings files are examined directly, its practical advantage becomes clearer: the strength of Xfce is not just lightness but visibility of structure. In Xfce, the location of settings for appearance, panels, window management, power management, and keyboard shortcuts is comparatively clear, and it is easier to trace what changes when a setting is modified. GNOME Flashback, by contrast, is tightly connected to GNOME’s configuration foundation, including dconf and gsettings, as well as session-side components such as gnome-session and gnome-settings-daemon. As a result, the scope of influence of a change is broader and troubleshooting tends to be somewhat more complex.
Accordingly, if the goal on a single machine is to use a GUI environment that is as simple, robust, and traceable as possible, Xfce is the more rational choice. If, on the other hand, the goal is to unify the operational feel across multiple GNOME-family hosts or to prioritize consistency with GNOME-family applications, then GNOME Flashback has operational advantages. Those differences can be summarized as follows.
| Viewpoint | Xfce | GNOME Flashback | Assessment |
|---|---|---|---|
| Design philosophy | A set of lightweight and relatively independent components | A lightweight session built on GNOME components | Their nature differs fundamentally |
| Structural simplicity | Very simple | Somewhat more complex because of GNOME dependency | Xfce has the advantage |
| Dependency footprint | Smaller | Larger | Xfce has the advantage |
| Number of resident processes | Smaller | Somewhat larger | Xfce has the advantage |
| Memory usage | Lower | Moderate | Xfce has the advantage |
| Startup speed | Fast | Somewhat slower | Xfce has the advantage |
| Observability | High | Somewhat lower because more processing is hidden inside GNOME-side components | Xfce has the advantage |
| Ease of understanding settings | The role of each configuration file is relatively easy to trace | More abstract because the center is dconf and gsettings | Xfce has the advantage |
| Centralization of configuration management | Split by function | Easier to aggregate under dconf | GNOME Flashback has the advantage |
| Environment reproducibility | Requires explicit understanding of individual settings | Relatively easy through mechanisms such as dconf dump and load | GNOME Flashback has the advantage |
| Consistency with GNOME applications | Works, but integration is not the main design center | High | GNOME Flashback has the advantage |
| Uniformity across GNOME-family hosts | Lower | Higher | GNOME Flashback has the advantage |
| Stability | High | Also high, but more exposed to changes in the GNOME base | Xfce is slightly favored |
| Impact of upstream changes | Comparatively smaller | More likely to be affected | Xfce has the advantage |
| Troubleshooting difficulty | Easier | Somewhat more complex | Xfce has the advantage |
| Tracing IME and input behavior | Comparatively simple | More likely to involve GNOME-side management | Xfce has the advantage |
| Session structure | Simple | Centered on gnome-session | Xfce has the advantage |
| Use as an SSH-managed maintenance terminal | Very suitable | Usable, but somewhat excessive | Xfce has the advantage |
| Use as a verification environment | Very suitable | Somewhat more complex | Xfce has the advantage |
| Use as a main desktop | Entirely possible | Easier to obtain a more unified overall feel | GNOME Flashback is slightly favored |
| UI uniformity | Weaker | Stronger | GNOME Flashback has the advantage |
| Long-term operational visibility | High | Requires continued awareness of GNOME-base dependency | Xfce is slightly favored |
| Ease of system-level understanding | High | Moderate | Xfce has the advantage |
What this comparison reveals is that Xfce’s strength is not merely that it is “simple and light.” More precisely, Xfce has a structure that is easier to see, a configuration layout that is easier to trace, and failure modes that are easier to isolate. That makes it well suited to maintenance terminals, verification terminals, auxiliary nodes, and personal machines where long-term maintainability matters. GNOME Flashback, by contrast, is stronger in consistency with GNOME-family environments, ease of exporting settings, and application-level integration, which can matter when multiple GNOME-family hosts are operated in parallel.
Therefore, if a conclusion must be stated after understanding Xfce’s configuration structure, it is this: for a single operational target, Xfce is generally the more straightforward and controllable choice. GNOME Flashback is better understood not as “a classical-looking lightweight desktop” but as “a session that keeps the GNOME design philosophy while making it comparatively light.” In other words, the difference is not primarily in appearance but in the structure behind the appearance. If the goal is to trace settings directly and operate the environment through explicit understanding, Xfce is the clearer fit.
9. Summary
This article organized Xfce configuration management in three layers: xfconf as the configuration system, channels as the logical structure, and XML files as the storage form. The important point is not to regard Xfce merely as “a place where configuration files happen to be stored,” but as a configuration architecture in which logical structure and stored state correspond to each other comparatively clearly [5][7].
From that perspective, the practical priorities are also clear. xsettings.xml and xfce4-keyboard-shortcuts.xml should be treated as first-class management targets, and xfwm4.xml is often worth carrying along as needed. By contrast, xfce4-panel.xml is important but has to be considered together with related files and plugin composition, while xfce4-power-manager.xml should be handled cautiously because of strong hardware dependence [13][14][15].
In that sense, Xfce is not simply a lightweight desktop environment. Because the location of settings and the boundary of responsibilities remain comparatively visible, it has a design well suited to long-term operation, environment reproduction, and multi-environment use including remote GUI. In actual operations, the most stable approach is to use that transparency deliberately and decide in advance which settings should be preserved and which should be reconfigured per environment.
References
- xrdp-sesman(8). https://manpages.debian.org/testing/xrdp/xrdp-sesman.8.en.html
- D-Bus Tutorial. https://dbus.freedesktop.org/doc/dbus-tutorial.html
- pam_systemd. https://www.freedesktop.org/software/systemd/man/pam_systemd.html
- systemd-logind.service. https://www.freedesktop.org/software/systemd/man/systemd-logind.service.html
- xfconf – Configuration Storage System. https://docs.xfce.org/xfce/xfconf/start
- Xfce Settings Manager Documentation. https://docs.xfce.org/xfce/xfce4-settings/start
- XDG Base Directory Specification. https://www.freedesktop.org/wiki/Specifications/basedir-spec/
- Gio Overview. https://docs.gtk.org/gio/overview.html
- dconf. https://wiki.gnome.org/Projects/dconf
- Xfce Appearance Settings. https://docs.xfce.org/xfce/xfce4-settings/appearance
- Keyboard Settings – Xfce Documentation. https://docs.xfce.org/xfce/xfce4-settings/keyboard
- xfce4-panel – Preferences. https://docs.xfce.org/xfce/xfce4-panel/preferences
- xfce4-panel – Xfce Panel. https://docs.xfce.org/xfce/xfce4-panel/start
- Xfce Panel Profiles. https://docs.xfce.org/apps/xfce4-panel-profiles/start
- Xfce Power Manager Preferences. https://docs.xfce.org/xfce/xfce4-power-manager/preferences
- Xfwm4 – Xfce Window Manager. https://docs.xfce.org/xfce/xfwm4/start
- Desktop Settings – Xfce Documentation. https://docs.xfce.org/xfce/xfdesktop/start
- xfconf-query. https://docs.xfce.org/xfce/xfconf/xfconf-query