Brainstorming: Improving Xfce's Out-of-the-Box Experience

daffyduck · 2026-07-29 23:53:35

I've been thinking about how to increase Xfce's popularity and attract new users. While the transition to Wayland is important and in progress, I believe there are more immediate hurdles regarding the initial user experience (UX), especially for distributions that ship "pure" upstream defaults.

Currently, a vanilla installation can feel "odd" and dated. Examples of possible gaps in the initial user experience include:

Scaling and Visuals: The default 96 DPI looks too small on most modern setups. Increasing it to 120 DPI would significantly improve the first-run experience, though this also highlights a related and pressing need for more WM decoration themes designed for higher DPI.
UI Familiarity: Xfce doesn't resemble the modern M$ Windows layouts that most new users are accustomed to, and it isn't easy to configure Xfce to mimic those layouts.
First-Run Configuration: There is no way to quickly set up initial preferences, like font DPI, matching WM themes, panel presets, and keyboard shortcuts. A new user can only get lost if he/she tries to do some configuration.

To address these, here are some ideas:

A "Best Practices" Guide: Helping distros set up a more polished, modern experience.
Config Presets: Providing example configs for distros (e.g., "Classic Xfce," "Win7," "Win10," and "Win11" layouts).
First-Run GUI app: An optional app that asks users for basic preferences upon first launch of Xfce (e.g., font DPI with a matching WM theme, panel layout presets, mouse speed/acceleration or touchpad settings, dark/light theme, and basic keyboard shortcuts).

What do you think?
Also, could someone post links to any relevant previous discussions or consensus that was previously reached about those issues?

Armacadia · 2026-07-30 06:42:13

Okay so here are the first few things I do on any new installs with Xfce. I'm not sure how much "vanilla" this default configuration is (I use Debian). What I end up with is looking more like a Windows 7-ish setup, though I wasn't deliberately going to replicate it, just went with whatever I felt was sensible after years of being mostly on Windows (so, obviously, biased). What I think are the very key usability related changes is highlighted in bold.

Remove the second panel with the app launcher. Why does it even exist?
Drag the main panel to the bottom (like Windows), change its vertical size from 26 to 28 pixels so that it's consistent with the title bars, replace the applications menu with Whisker, bind xfce4-popup-whiskermenu to both Super/Win/whatever you call it keys.
For the Whisker menu: disable "Show application descriptions", set the default category to "Recent applications" (I don't have a lot of apps so everything I need fits full well like that, otherwise I probably would've used Favorites more), enable "Switch categories on hovering".
For Window Buttons: enable "Flat buttons" (it's a bit broken here and ocassionally shows their backgrounds anyway), disable "Show handle", set middle click action to "New instance", set sorting to "None". Really wish it had an option to not group the same app's buttons until there's no more space (equivalent of Windows' "Combine when taskbar is full"). Switching windows by using the scroll whell is a nifty feature so I keep it on.
Remove any extra separators from the panel except the transparent expanding one between Window Buttons and Status Tray. Remove Notifications Plugin, I wish it was useful but it just isn't. Remove Action Buttons, the Whisker menu provides them. Add Show Desktop to the very end.
In Appearance: enable slight hinting and RGB pixel order. Honestly I wish I could turn off font antialiasing completely and have it look decent, but to this day I can't find any suitable for UI font on Linux that would do that. (Sorry, Unifont is too extreme.) In general, the default fonts and scales feel way too oversized for my ancient 1280x1024 monitor... coping with that somehow, thinking it would look more reasonable on FHD and up, but ideally rather have it be as small as possible with an option to scale up manually. Older versions of Xfce had a nicer default scale (the one that came with Xubuntu 18.04 as an example, was it 4.16 or something?)
For the Window Manager: remove the shade button, align titles to the left, as center is centered relative to the free space left in the title bar instead of full title bar width and that looks ugly.
For Thunar, change the date format to "Today at..."
Finally for the Xfce terminal I enable "Use system font" and set a custom color palette (black on white, GTK colors, would've used the same colors in Mousepad but there's no GUI for customizing the palette so I don't bother).

Please don't raise the default DPI any further for the time being (or at least until you're positive absolutely everyone has 2K and beyond displays, which as well might never happen). For those of us with older monitors, barely anything fits already. Same goes for the previous website redesign suggestion. Just no.

I don't find the configuration process of Xfce particularly difficult to get around in, at least for the basics I have listed above, there's a fairly usable Settings Manager window. But I do think it would be a good idea to prompt the user to set the DPI, font hinting type and color scheme on first startup, and perhaps also a choice between the classic and Whisker menus.

What I really miss here is a black Adwaita theme out of the box. Sure it would probably be against the GTK guidelines, but I can't stand the gray, so I stick to the light Adwaita theme 90% of the time unless my eyes are really tired. If there also was something that could let the user change the default blue accent color for those, that'd be totally awesome. I think Xubuntu shipped with gtk-theme-config at some point but later it was broken and removed? Is modifying the default themes something that's still easily possible at all???

About the config presets... I don't know. I appreciate software that doesn't try to mimic other software too much, especially if it's more popular, and just has its own aesthetics. Windows 7 had become the de facto "generic" desktop metaphor based environment so I don't think my setup looks too Windows-y, there are some behavioral resemblances but it's also fairly different.

Last edited by Armacadia (2026-07-30 07:10:32)

daffyduck · 2026-07-30 07:04:01

Armacadia wrote:

About the config presets... I don't know. I appreciate software that doesn't try to mimic other software too much, especially if it's more popular, and just has its own aesthetics. Windows 7 had become the de facto "generic" desktop metaphor based environment so I don't think my setup looks too Windows-y, there are some behavioral resemblances but it's also fairly different.

Config presets, whether delivered via a first-run GUI or provided as examples, are actually the key. They are less about mimicking specific versions of Windows and more about catering to user diversity.

Because, look at your post. Just like you, every user is going to have his/hers own preferences. Since a single default can't satisfy everyone, providing multiple easy-to-apply presets is the best way to accommodate a wider range of users. Windows-alike interface is just something that new users are most familiar with, based on available OS usage statistics, so that's why I suggested it, but there could be other options.

In general, the default fonts and scales feel way too oversized for my ancient 1280x1024 monitor... coping with that somehow,

That's a pretty low resolution by modern standards, so it probably isn't representative of the majority. 1280x1024 is likely used by fewer than 5% of users today.
The problem is that what feels "normal" for the majority might be too large for those older monitors.

The best way to handle this would be to ensure the "first-run" GUI app fits that resolution and lets the user choose their DPI right at the start.

Last edited by daffyduck (2026-07-30 07:25:53)

Armacadia · 2026-07-30 07:20:08

daffyduck wrote:

Windows-alike interface is just something that new users are most familiar with, based on available OS usage statistics, so that's why I suggested it, but there could be other options.

Yeah I see where you're going, if that gets done maybe just avoid calling the presets "X-like" or "Y-like" and come up with something more original... and then everyone's going to see what it's trying to be anyway, which once again puts Linux desktops in that unfortunate position where it always feels like it's trying to look like something better than it is but never really fully gets there.

daffyduck · 2026-07-30 07:32:19

Armacadia wrote:

Yeah I see where you're going, if that gets done maybe just avoid calling the presets "X-like" or "Y-like" and come up with something more original... and then everyone's going to see what it's trying to be anyway, which once again puts Linux desktops in that unfortunate position where it always feels like it's trying to look like something better than it is but never really fully gets there.

Nope, quite the opposite.
The user can't chose a preset if it doesn't have a clear recognizable name. Therefore, presets like "Win7" / "Win10" are in fact good.
Originality means decreased familiarity. That is not appreciated by the majority.

Here I offer evidence.

When downloading custom themes from
https://www.opendesktop.org/browse?cat=138&ord=latest
then it is obvious from the statistics (at the bottom of that page), than non-original themes, i.e. copycats, are by far the most popular.

So, originality is a bad idea. Don't invent, instead copy from big companies that have invested billions into designing user interfaces.

Added later 15 h 23 min 13 s:
If it wasn't clear in the original post, "keyboard shortcuts" would also be presets.

For example, there could be keyboard presets named:
"Classic XFCE"
"GNOME"
"KDE"
"Windows" (all versions of M$ Windows have consistent keyboard shortcuts)
"Mac OS"
"CDE / Motif"

But, for simplicity, keyboard preset would automatically match the user-selected panel layout preset, while also providing an option to select a different keyboard preset if desired.
So, no need to set each individual keyboard shortcut separately.

Added later 15 h 31 min 26 s:
And, another cool feature:

The "first-run" GUI app should offer to the user automatic install of the Whisker menu if it is available in the repos, or if Whisker is already installed, to integrate it into the panel.

That logic is based on the popularity of CachyOS: it offers to users one-click installations of important applications, on the first run.

treeview · 2026-07-31 10:57:58

daffyduck wrote:

I've been thinking about how to increase Xfce's popularity and attract new users. While the transition to Wayland is important and in progress, I believe there are more immediate hurdles regarding the initial user experience (UX), especially for distributions that ship "pure" upstream defaults.
Currently, a vanilla installation can feel "odd" and dated. Examples of possible gaps in the initial user experience include:
Scaling and Visuals: The default 96 DPI looks too small on most modern setups. Increasing it to 120 DPI would significantly improve the first-run experience, though this also highlights a related and pressing need for more WM decoration themes designed for higher DPI.
UI Familiarity: Xfce doesn't resemble the modern M$ Windows layouts that most new users are accustomed to, and it isn't easy to configure Xfce to mimic those layouts.
First-Run Configuration: There is no way to quickly set up initial preferences, like font DPI, matching WM themes, panel presets, and keyboard shortcuts. A new user can only get lost if he/she tries to do some configuration.
To address these, here are some ideas:
A "Best Practices" Guide: Helping distros set up a more polished, modern experience.
Config Presets: Providing example configs for distros (e.g., "Classic Xfce," "Win7," "Win10," and "Win11" layouts).
First-Run GUI app: An optional app that asks users for basic preferences upon first launch of Xfce (e.g., font DPI with a matching WM theme, panel layout presets, mouse speed/acceleration or touchpad settings, dark/light theme, and basic keyboard shortcuts).
What do you think?
Also, could someone post links to any relevant previous discussions or consensus that was previously reached about those issues?

WA WA WA why can't Xfce look and work more like Mac or Windows.... Wash, Rinse, Repeat!
I've been swimming in the Linux pool for 20+ years, and this thread, like many, many discussions in the Linux community immediately and completely miss the point and purpose of GNU/Linux. Everyday someone has a sudden epiphany and decides to share their previously overlooked brilliance. D'oh!

daffyduck · 2026-07-31 11:31:54

treeview wrote:

WA WA WA why can't Xfce look and work more like Mac or Windows.... Wash, Rinse, Repeat! !

I did ask “what do you think”, so thank you for the reply.

The fact that others have pointed out the same lack of functionality is itself an argument in favor of lookalike copycats.

I've been swimming in the Linux pool for 20+ years, and this thread, like many, many discussions in the Linux community immediately and completely miss the point and purpose of GNU/Linux.

There isn’t one single “point and purpose” of GNU/Linux. Different distros have different goals.
You have been swimming in the Linux pool for 20+ years, and still haven’t learned that user feedback is part of making good software.

Everyday someone has a sudden epiphany and decides to share their previously overlooked brilliance. D'oh

You can't convince me that suggesting improvements is useless.

treeview · 2026-07-31 11:48:17

daffyduck wrote:

treeview wrote:
WA WA WA why can't Xfce look and work more like Mac or Windows.... Wash, Rinse, Repeat! !
I did ask “what do you think”, so thank you for the reply.
The fact that others have pointed out the same lack of functionality is itself an argument in favor of lookalike copycats.
I've been swimming in the Linux pool for 20+ years, and this thread, like many, many discussions in the Linux community immediately and completely miss the point and purpose of GNU/Linux.
There isn’t one single “point and purpose” of GNU/Linux. Different distros have different goals.
You have been swimming in the Linux pool for 20+ years, and still haven’t learned that user feedback is part of making good software.
Everyday someone has a sudden epiphany and decides to share their previously overlooked brilliance. D'oh
You can't convince me that suggesting improvements is useless.

FWIW, the "point and purpose" of GNU/Linux is proven by the 1000+ available distributions, but I "still haven't learned"? Thanks for sharing even more of your brilliance...my bad, I guess I stand corrected? Thanks!

daffyduck · 2026-07-31 12:22:25

treeview wrote:

FWIW, the "point and purpose" of GNU/Linux is proven by the 1000+ available distributions, but I "still haven't learned"? Thanks for sharing even more of your brilliance...my bad, I guess I stand corrected? Thanks!

If I understand your point correctly, you're suggesting that the existence of over 1,000 distributions proves the success and purpose of GNU/Linux because it avoided simply copying Windows GUI.

First, the variety of distributions hasn't translated to mass adoption. GNU/Linux desktop market share remains under 6%, and that figure has barely moved in two decades despite the proliferation of different distros.

Second, the implied idea that these distributions avoid copying the Windows GUI is inaccurate. Some of the most popular distros (like Zorin, Mint, and AnduinOS) explicitly copy the Windows GUI to attract users. The popularity of these distros validates the copycat strategy.

treeview · 2026-07-31 13:57:30

daffyduck wrote:

treeview wrote:
FWIW, the "point and purpose" of GNU/Linux is proven by the 1000+ available distributions, but I "still haven't learned"? Thanks for sharing even more of your brilliance...my bad, I guess I stand corrected? Thanks!
If I understand your point correctly, you're suggesting that the existence of over 1,000 distributions proves the success and purpose of GNU/Linux because it avoided simply copying Windows GUI.
First, the variety of distributions hasn't translated to mass adoption. GNU/Linux desktop market share remains under 6%, and that figure has barely moved in two decades despite the proliferation of different distros.
Second, the implied idea that these distributions avoid copying the Windows GUI is inaccurate. Some of the most popular distros (like Zorin, Mint, and AnduinOS) explicitly copy the Windows GUI to attract users. The popularity of these distros validates the copycat strategy.

To ignorantly believe the success of GNU/Linux must be measured by acceptance in market share and simple appearance, shows you still completely fail to resonate with the "point and purpose" of the OS. GNU/Linux was/is offered as a mainstream alternative which provides anyone with the ultimate configuration for specific wants and need(s). GNU/Linux will never be "mass adopted" because our world is comprised of a tribes of Indians, not courageous Chiefs. Being a GNU/Linux user places individuals in unique camp of fearless and principled leaders unwilling to adhere to the illusory boundaries of the status quo, so congratulations, you're a winner of a few on a hyper-novel level who've excitedly recognized the empowering path of the "road less traveled". drops mic

Edit:
P.S. https://youtu.be/0Ka7VUEKBnc

Last edited by treeview (2026-07-31 15:10:29)

daffyduck · 2026-07-31 18:11:11

treeview wrote:

To ignorantly believe the success of GNU/Linux must be measured by acceptance in market share and simple appearance, shows you still completely fail to resonate with the "point and purpose" of the OS.

There is no single GNU/Linux OS. Instead, there are over a thousand somewhat compatible distributions, each effectively being a separate OS.

As I have said, there is no single "point and purpose" of GNU/Linux. If there is one, please provide a URL to the document that clearly declares this supposed purpose. I could then look for each distribution's explicit endorsement of such a document. The only catch is that no such document exists, nor has anyone ever heard of anything remotely similar.

GNU/Linux was/is offered as a mainstream alternative which provides anyone with the ultimate configuration for specific wants and need(s).

The GNU project has a principle somewhat similar to that, in terms of the freedoms they defined, but "ultimate configuration" is not the proper way to interpret it. The Linux kernel and its author did not quite share that same objective.

GNU/Linux will never be "mass adopted"

That is a questionable forecast I would not dare to make.

Regardless, even if a distribution's primary goal is not to have a large user base, most (but not all distros) still prefer to be well-accepted and adopted by the masses.

because our world is comprised of a tribes of Indians, not courageous Chiefs. Being a GNU/Linux user places individuals in unique camp of fearless and principled leaders unwilling to adhere to the illusory boundaries of the status quo, so congratulations, you're a winner of a few on a hyper-novel level who've excitedly recognized the empowering path of the "road less traveled".

This is largely an overgeneralization, partly fantasy, and in the remaining parts, not a relevant argument.

treeview · 2026-07-31 22:38:12

daffyduck wrote:

There is no single GNU/Linux OS. Instead, there are over a thousand somewhat compatible distributions, each effectively being a separate OS.

I will conclude that you don't agree that Linus Torvalds created a open source operating system (OS) for computers leading to the widely used Linux kernel.
And as much as this banter is agreeably expected, I'll let your thread go and let you get back to your OP "brainstorming to improve Xfce's out-of-the-box experience". ¯\_(ツ)_/¯

daffyduck · 2026-08-01 02:31:26

treeview wrote:

I will conclude that you don't agree that Linus Torvalds created a open source operating system (OS) for computers leading to the widely used Linux kernel.
And as much as this banter is agreeably expected, I'll let your thread go and let you get back to your OP "brainstorming to improve Xfce's out-of-the-box experience". ¯\_(ツ)_/¯

Linux is a kernel, created by Linus Torvalds, not a full operating system. It doesn't even include a desktop environment, which is what Xfce is.
A distribution adds the necessary components to the kernel to create a complete OS. Compared to the entire distro, the kernel is only one small part of the whole.

It is not really just that "I don't agree", as it is a well-known fact, easily verified anywhere.

treeview · 2026-08-01 09:14:34

daffyduck wrote:

It is not really just that "I don't agree", as it is a well-known fact, easily verified anywhere.

Huh, you began your second paragraph with what I concluded in my first of the last reply, which is clearly "verified" within this thread i.e., 'you'll never agree'...yeah, I kinda picked up on that from your very first reply, and why I played along, you're very good at what it is that you do!
Bless your heart! I'm also guessing you think IQ is overrated because you're able to "brainstorm" many things with many people, so I'll let you have the last word and leave you to it. Good Luck!

Last edited by treeview (2026-08-01 09:15:10)

ToZ · 2026-08-01 10:09:58

This conversation is starting to go off the rails. Lets stay respectful.

daffyduck · 2026-08-02 00:34:59

This post contains some additional ideas for the "first-run GUI app".

The first-run GUI app can be named xfce4-first-run. It needs to integrate smoothly with the "Welcome" apps that many distributions already use.

Instead of a monolithic wizard that competes with Welcome apps, I propose making xfce4-first-run controllable via command-line parameters, allowing it to be called as a component from within any Welcome app.

By making xfce4-first-run a modular backend, a distro can trigger only the exact configuration dialogs they want the user to see.

The CLI syntax would have two different modes. The following command demonstrates the inclusive mode, which lists the dialogs to be displayed:

xfce4-first-run  dpi  pointer-speed  layout theme  whisker  keyboard

To display all available dialogs, just this is sufficient:

xfce4-first-run

And for the exclusive mode, which skips the listed dialogs:

xfce4-first-run  -theme  -dpi  -pointer-speed

Of course, the distro Welcome app can call xfce4-first-run multiple times, each time with different command-line options.

(added later, but inserted here for clarity):
The "keyboard" dialog requires a known layout preset to determine the default selection. This command exemplifies how to communicate a previously selected layout preset:

xfce4-first-run  -layout=Win10  keyboard

Added later 4 h 16 min 19 s:
Another issue is how xfce4-first-run would determine which WM themes are appropriate for a given font DPI setting?

To solve this, xfce4-first-run should utilize its own first-run-config configuration file. This file would contain a list specifying the DPI range that each WM theme covers effectively, in a format like this:

WinDecor   Daloa      60   100
WinDecor   Kokodi     80   130
WinDecor   Moheli     70   115
WinDecor   WM-theme-name-3     90  140
WinDecor   WM-theme-name-4     90  110

With this setup, the "themes" selection dialog of xfce4-first-run would show only those WM themes whose DPI range includes the currently applied DPI value. Xfce would provide the contents of a default recommended first-run-config file, which distributions could then easily modify to suit their needs.

This same configuration file could also be used to define the exact commands required to install the Whisker menu, and similar data.

Added later 4 h 43 min 50 s:
Another possible enhancement: for each WM and widget theme, the first-run-config file could include a list specifying whether the theme is "dark" or "bright", like this for widget themes:

Theme   Adwaita         bright
Theme   Adwaita-dark    dark
Theme   Breeze          bright

This would allow the "themes" selection dialog to present the selection process using separate UI controls. For example, the user could first use a bright/dark toggle, which would immediately filter the displayed lists of available widget and WM themes.

That is intended to slightly decrease the user's cognitive load.

For theme names, the '/' character can serve as an escape character (e.g., '//' for a slash and '/ ' for a space), just in case a theme name contains spaces. An alternative syntax proposal would be to end theme names with a character that cannot appear in theme names.

Added later 6 h 36 min 35 s:
For the "layout" and "keyboard" dialogs, the first-run-config file would map each layout preset to a corresponding keyboard preset and a configuration directory. For example:

Layout  Win7     Win    /usr/share/xfce4-first-run/layouts/win7
Layout  Win10    Win    /usr/share/xfce4-first-run/layouts/win10
Layout  GNOME    GNOME  /usr/share/xfce4-first-run/layouts/gnome
KeyboardShortcutsDir  /usr/share/xfce4-first-run/keyboard/

Here is an alternative proposal for the syntax:

LayoutsDir  /usr/share/xfce4-first-run/layouts/
Layout  Win7   Win
Layout  Win10  Win
Layout  GNOME  GNOME
KeyboardShortcutsDir  /usr/share/xfce4-first-run/keyboard/

This approach allows a panel layout preset, such as "Win7" and "Win10", to be associated with a keyboard shortcuts preset ("Win").

xfce4-first-run should communicate the user's layout selection back to the caller via standard output using a simple Key Value format, like:

Layout Win10

The keyboard shortcuts would be stored in a file:
<KeyboardShortcutsDir> / <KeyboardPresetName> / keyboard-shortcuts.conf
This file would contain the arguments to be passed to xfconf-query to apply each shortcut one by one, like in this example:

/commands/custom/<Super>e   thunar
/commands/default/<Super>t  exo-open --launch TerminalEmulator
/xfwm4/custom/<Alt>Tab      cycle_windows_key
/xfwm4/default/<Alt>F4      close_window_key

(added later):
To prevent destructive overwrites, actions to apply a keyboard preset in the "keyboard" dialog should be guarded by a shortcuts preservation flag, stored in xfconf.

If the flag is true or not present when the user attempts an action to apply a keyboard preset, xfce4-first-run should present a confirmation popup with three options:
- "Cancel"
- "Destroy" (wipe the entire xfce4-keyboard-shortcuts channel and then apply new shortcuts)
- "Merge" (preserve existing shortcuts that do not conflict with new ones)

If the flag is false, then there is no additional confirmation, and the action is the same as "Destroy".

The shortcuts preservation flag is set to "true" whenever a keyboard preset is successfully applied. The initial value of this flag should be "false", set by the Xfce installation script whenever it determines there was no previous Xfce configuration or the user wants to completely discard any previous Xfce configuration.

Added later 7 h 46 min 04 s:
The "theme" dialog can be completely independent of the "layout" dialog, as there is no need for the selected layout preset to restrict the theme selection.

The first-run-config file could specify a list of suggested themes for each layout preset, allowing suggested themes to appear at the top of the list, with the first one selected by default. For example:

SuggestedDecor   Win7    AeroClone  AeroSkyClone  AeroVioletClone
SuggestedDecor   Win10   Win10Clone
SuggestedDecor   GNOME   GnomeClone
SuggestedThemes  GNOME   Adwaita  Adwaita-dark

Added later 8 h 29 min 04 s:
To make the "suggested themes" functionality work, xfce4-first-run must know which layout was previously applied, even if the "layout" and "theme" dialogs are displayed on separate runs.

The caller can pass a previously selected layout preset to xfce4-first-run using this syntax:

xfce4-first-run  -layout=Win10  theme

While the "theme" dialog also requires the current DPI to filter available themes, the current DPI can be read directly from xfconf, so it does not need to be passed as a command-line parameter.

Last edited by daffyduck (2026-08-02 11:18:35)

treeview · 2026-08-02 10:20:40

daffyduck wrote:

This post contains some additional ideas for the "first-run GUI app".
The first-run GUI app can be named xfce4-first-run. It needs to integrate smoothly with the "Welcome" apps that many distributions already use.
Instead of a monolithic wizard that competes with Welcome apps, I propose making xfce4-first-run controllable via command-line parameters, allowing it to be called as a component from within any Welcome app.
By making xfce4-first-run a modular backend, a distro can trigger only the exact configuration dialogs they want the user to see.
The CLI syntax would have two different modes. The following command demonstrates the inclusive mode, which lists the dialogs to be displayed:
xfce4-first-run  dpi  pointer-speed  layout theme  whisker  keyboard
To display all available dialogs, just this is sufficient:
xfce4-first-run
And for the exclusive mode, which skips the listed dialogs:
xfce4-first-run  -theme  -dpi  -pointer-speed
Of course, the distro Welcome app can call xfce4-first-run multiple times, each time with different command-line options.
(added later, but inserted here for clarity):
The "keyboard" dialog requires a known layout preset to determine the default selection. This command exemplifies how to communicate a previously selected layout preset:
xfce4-first-run  -layout=Win10  keyboard
Added later 4 h 16 min 19 s:
Another issue is how xfce4-first-run would determine which WM themes are appropriate for a given font DPI setting?
To solve this, xfce4-first-run should utilize its own first-run-config configuration file. This file would contain a list specifying the DPI range that each WM theme covers effectively, in a format like this:
WinDecor   Daloa      60   100
WinDecor   Kokodi     80   130
WinDecor   Moheli     70   115
WinDecor   WM-theme-name-3     90  140
WinDecor   WM-theme-name-4     90  110
With this setup, the "themes" selection dialog of xfce4-first-run would show only those WM themes whose DPI range includes the currently applied DPI value. Xfce would provide the contents of a default recommended first-run-config file, which distributions could then easily modify to suit their needs.
This same configuration file could also be used to define the exact commands required to install the Whisker menu, and similar data.
Added later 4 h 43 min 50 s:
Another possible enhancement: for each WM and widget theme, the first-run-config file could include a list specifying whether the theme is "dark" or "bright", like this for widget themes:
Theme   Adwaita         bright
Theme   Adwaita-dark    dark
Theme   Breeze          bright
This would allow the "themes" selection dialog to present the selection process using separate UI controls. For example, the user could first use a bright/dark toggle, which would immediately filter the displayed lists of available widget and WM themes.
This is intended to slightly decrease the user's cognitive load.
For theme names, the '/' character can serve as an escape character (e.g., '//' for a slash and '/ ' for a space), just in case a theme name contains spaces. An alternative syntax proposal would be to end theme names with a character that cannot appear in theme names.
Added later 6 h 36 min 35 s:
For the "layout" and "keyboard" dialogs, the first-run-config file would map each layout preset to a corresponding keyboard preset and a configuration directory. For example:
Layout  Win7     Win    /usr/share/xfce4-first-run/layouts/win7
Layout  Win10    Win    /usr/share/xfce4-first-run/layouts/win10
Layout  GNOME    GNOME  /usr/share/xfce4-first-run/layouts/gnome
KeyboardShortcutsDir  /usr/share/xfce4-first-run/keyboard/
Here is an alternative proposal for the syntax:
LayoutsDir  /usr/share/xfce4-first-run/layouts/
Layout  Win7   Win
Layout  Win10  Win
Layout  GNOME  GNOME
KeyboardShortcutsDir  /usr/share/xfce4-first-run/keyboard/
This approach allows a panel layout preset, such as "Win7" and "Win10", to be associated with a keyboard shortcuts preset ("Win").
To maintain a stateless backend, xfce4-first-run should communicate the user's layout selection back to the caller via standard output using a simple Key Value format, like:
Layout Win10
The keyboard shortcuts would be stored in a file:
<KeyboardShortcutsDir> / <KeyboardPresetName> / keyboard-shortcuts.conf
This file would contain the arguments to be passed to xfconf-query to apply each shortcut one by one, like in this example:
/commands/custom/<Super>e   thunar
/commands/default/<Super>t  exo-open --launch TerminalEmulator
/xfwm4/custom/<Alt>Tab      cycle_windows_key
/xfwm4/default/<Alt>F4      close_window_key
Before these keyboard shortcuts are applied, the xfce4-keyboard-shortcuts channel should be completely cleared.
Added later 7 h 46 min 04 s:
The "theme" dialog can be completely independent of the "layout" dialog, as there is no need for the selected layout preset to restrict the theme selection.
The first-run-config file could specify a list of preferred themes for each layout preset, allowing preferred themes to appear at the top of the list, with the first one selected by default. For example:
SuggestedDecor   Win7    AeroClone  AeroSkyClone  AeroVioletClone
SuggestedDecor   Win10   Win10Clone
SuggestedDecor   GNOME   GnomeClone
SuggestedThemes  GNOME   Adwaita  Adwaita-dark
Added later 8 h 29 min 04 s:
To make the "preferred themes" functionality work, xfce4-first-run must know which layout was previously applied, even if the "layout" and "themes" dialogs are displayed on separate runs.
The caller can pass a previously selected layout preset to xfce4-first-run using this syntax:
xfce4-first-run  -layout=Win10  theme
While the "theme" dialog also requires the current DPI to filter available themes, the current DPI can be read directly from xfconf, so it does not need to be passed as a command-line parameter.

Forgive my prior jesting, I for one sincerely appreciate your effort and vision, and eagerly await another Linux distribution w/Xfce, but finally one done right (e.g., DaffyDuck GNU/Linux), which would perfectly exemplify the ethos that is the Linux free and open source platform! Many others are doing just that, why not you, Yes?

daffyduck · 2026-08-02 10:36:04

treeview wrote:

Forgive my prior jesting, I for one sincerely appreciate your effort and vision, and eagerly await another Linux distribution w/Xfce, but finally one done right (e.g., DaffyDuck GNU/Linux), which would perfectly exemplify the ethos that is the Linux free and open source platform! Many others are doing just that, why not you, Yes?

The design of xfce4-first-run is specifically intended to facilitate easy integration into the "Welcome" apps of existing popular distributions. That should remove the need for a new distro just for running xfce4-first-run.

gogogadget · 2026-08-02 17:49:11

(I'm not concerned by this topic, by the way, I can configure my desktop to my needs)

treeview wrote:

so I'll let you have the last word and leave you to it. Good Luck

Looks like you can't, you're full of shit.

If Linux is just a kernel and some apps, what's the point of using distributions, go LFS.

(It's a forum dedicated to a desktop environment)

daffyduck · 2026-08-02 19:54:04

This addition is necessary for distributions that provide the vanilla Xfce configuration:

Xfce desktop should, by its default configuration, ensure that the xfce4-first-run program is automatically run on the first run of Xfce. Once the xfce4-first-run wizard has been completed, the program should not subsequently be run automatically. That is to be accomplished as described below.

xfce4-session is responsible for autostarting xfce4-first-run. At the beginning of each session, xfce4-session checks the xfconf flag named first-run-autorun. If the flag is set to true, it launches the xfce4-first-run program with no arguments.

The xfce4-first-run program manages its autostart state as follows:
- If the user checks the "don't show this anymore" checkbox in the GUI, the first-run-autorun flag must be set to false immediately.
- If the program is launched with the -autorun-again command line option, it must set the flag to true at its launch.
- Otherwise, it must set the flag to false immediately after the user completes the final requested dialog.

The initial value of the first-run-autorun flag is set by the Xfce installation script. If the flag is not already present in xfconf, the script must set it to true for fresh installations and false for upgrades.

Added later 3 h 12 min 54 s:
Errata and other changes:

"first-run-config" was the suggested name of the configuration file for "xfce4-first-run". Instead, "first-run.conf" is a better filename given its syntax.
Regarding theme names, they are syntactically directory names with no additional restrictions on permitted characters, meaning the slash is the only disallowed character in a theme name. Consequently, there are two possibilities for the allowed syntax, one of:
- Every theme name must be terminated by a slash.
- Every space, tab, and newline character in a theme name must be escaped by a slash (i.e. "/ ", "/t", "/n"), as these whitespace characters are special characters in the syntax of "first-run.conf" file.
I think the second option is better, but I'm not sure.
A possible problem is the need to allow spaces in the names of presets, but space is instead a syntactic separator. The best fix: in the GUI, display underscores as spaces. Therefore, a preset named "Win_7" would be displayed as "Win 7".

Added later 8 h 19 min 11 s:
I forgot the parsing rules and escape characters for paths. Here is a simple and practical proposal:

To handle paths containing whitespace, the path parser should support two formats:

- EOL paths: If the path starts with "/", the remainder of the line is included as the path, with trailing whitespace (tabs and spaces) stripped.
- Bracketed paths: If the path starts with "[", it is parsed until the matching "]" is found (requires counting nested brackets, but not counting escaped brackets). Inside brackets, "|" is the escape character: "||" for "|", "|[" for "[", "|]" for "]", "| " for space, "|t" for tab, and "|n" for newline. These additions are also practical: "|i" for "|", "|_" for space, "|(" for "[", "|)" for "]".
- All other formats are considered invalid.

Then, perhaps, the theme names should also allow the same escape character sequences, with "|", in order for the rules to be more uniform? And then, perhaps also disallow "/" as the escape character ?

Comments: If a "#" is preceded by a whitespace character (tab, space or a newline), and is not inside a path nor inside a theme name, it starts a comment until the end of the line.

UTF-8 encoding (futuristic): UTF-8 is becoming more popular, so perhaps a UTF-8 variant should be allowed? One goal is that text editors should be able to easily figure out the file type. Here is a quick proposal: If the ".conf" file starts with a UTF-8 BOM, then it is a "UTF-8-encoded conf file". For such a file to be valid, it must begin with the UTF-8 BOM, immediately followed by "#.conf UTF-8 file v1.0". The rest of the first line is ignored and may contain only valid UTF-8 characters. Paths and theme names could then contain only valid UTF-8 characters, otherwise the file is invalid... Unfortunately, this support for UTF-8 doesn't seem very easy to implement. So, perhaps better not for now.

(added later)
Invalid characters in identifiers of presets: # | / [ ] whitespace, and anything outside the range 32 to 126
Also: "_" should be displayed in the GUI as a space.

Last edited by daffyduck (2026-08-03 09:41:01)

JmaCWQ · 2026-08-03 07:32:50

This addition is necessary for distributions that provide the vanilla Xfce configuration......

Why?
What is wrong with the current configuration those distros choose to provide?
Who's going to do all the things you're proposing?
You?

daffyduck · 2026-08-03 07:59:40

JmaCWQ wrote:

Why?

As explicitly stated at the start of this thread, the goal is to increase the popularity of XFCE. The approach I'm proposing is commonly known as "onboarding" or "initial user experience". I'm sure you can find plenty of articles about it on the web.

What is wrong with the current configuration those distros choose to provide?

We can only guess, but one thing is certain: XFCE is losing market share. My best guess is that most distros aren't providing a good enough initial XFCE experience.

Who's going to do all the things you're proposing?

Hard to tell. But you have to start with something, whether it's a spec, a description, or just an idea. You can't start with nothing, otherwise you're always stuck at the beginning.

You?

Why not? Perhaps it will be me, perhaps somebody else. I don't have a crystal ball.

Added later 18 min 32 s:
Here are the first two articles I found about onboarding. I haven't read them yet, but they look okay at first glance:
https://www.userflow.com/blog/onboardin … mpressions
https://formbricks.com/blog/user-onboar … -practices

Last edited by daffyduck (2026-08-03 08:03:02)

treeview · 2026-08-03 09:56:56

gogogadget wrote:

(I'm not concerned by this topic, by the way, I can configure my desktop to my needs)
Looks like you can't, you're full of shit.
If Linux is just a kernel and some apps, what's the point of using distributions, go LFS.
(It's a forum dedicated to a desktop environment)

You caught me, your critical review of the dialog thread completely exposes the fact I'm full of shite and I again stand corrected. Thank you for your heroic gatekeeping, forums like this need a tribe of competence to shutdown wrong think and discussion they believe not pertinent to the topic or groupthink. But was it?
GNU/Linux is so much more than a kernel, some apps and a choice of desktop UI, "Linux" means an unbound vision providing imaginative space to create both anything and nothing new, Xfce (which I personally appreciate as is) cleverly and simply provides a perfectly proven stable canvas/whiteboard foundation beginning a journey to infinity and beyond, but it takes courage evident by @daffyducks topic and his ability to allow others a glimpse of what he sees.
I still believe a DaffyDuck GNU/Linux would be another welcomed addition to the wanderings which is Linux. Yes?

Last edited by treeview (2026-08-03 20:17:41)

daffyduck · 2026-08-03 18:56:08

Some thoughts on the first dialogue. This part is arguably the most important because, without proper language and DPI settings, every subsequent window in the wizard could be the wrong size or in the wrong language.

This dialogue should only appear if the dpi, welcome, or language command-line options are enabled. If none is enabled, the app should just skip straight to the next requested dialogue.

Note about measures: all pixel-size measures in this proposal are specified at 96 DPI.

There is a potential issue with older displays and low-res virtual machines. To make sure this works everywhere, the first dialogue needs to be compact, probably fitting within a 900 × 600 pixel area. Since it is impossible to make it work on every single small display, the application should perform a check at launch; if the dialogue cannot fit the screen, the application should exit immediately.

Note that a change to the DPI will immediately affect the size of the dialogue window itself, in real-time.
All fonts should be sans-serif, where the best font is the most plain one, unadorned in style.

When welcome, dpi, and language are all enabled, the dialogue should display the following:

A short welcome message:
    - "Welcome to XFCE!"  (in a font of title size, height of lowercase "x" ~11.5px, best if bold)
    - (in font of text size, height of lowercase "x" ~7.1px)
        - "Let's get your new desktop environment set up."
        - "Choose your preferred language and display scaling."

Scaling settings (in an oversized thin font, lowercase "x" height ~13px, arranged in one row):
    - "Scaling:"  (a text label)
    - A text box for entering a numerical DPI value
    - Two oversized buttons (96px × 48px) labeled "-" and "+"

Language settings (in an oversized thin font, "x" height ~13px, arranged in one row):
        - "Language:" (a text label)
        - A language dropdown list, or similar UI control

Instructional text (text font, lowercase "x" height ~7.1px):
    - "Use the mouse or keyboard to adjust the settings to your liking."
    - (Invisible until the user interacts with the interface):
        - 'When you are satisfied, click "Next" to proceed.'

At the bottom, an area separated by a visible line or a different background color:
    - (text font, lowercase "x" height ~7.1px)
        - the following button is visible before the user interacts with the interface:
            - A "Skip" button on the LEFT (standard size, approx. 26px height)
                - when this button is clicked on, it simply disappears, but it makes
                     the other two buttons appear.
        - the following buttons are invisible until the user interacts with the interface above:
            - An "Exit" button in the middle (standard size, approx. 26px height)
            - A "Next ->" button on the right (slightly oversized, approx. 32px height)

The dialogue must apply both settings (language and scaling) immediately in real-time as the user interacts with the interface, so the user sees the effect of the changes instantly.

Added later 14 min 50 s:
When the "Exit" button is clicked, or the application receives a close request (e.g., clicking the window's "close" button, or receiving a system "close" signal), a confirmation popup appears with the following:
"Exit Setup Wizard?"
"Are you sure you want to quit?"
Checkbox: "Don't show this wizard again" (initially not checked)
Buttons: "Back" and "Quit"

Added later 1 h 37 min 39 s:
Since the application performs a screen-size check on the first window it displays, all dialogue windows should be the same size to ensure that if the first one fits the screen, all subsequent ones do as well.

Added later 2 h 22 min 21 s:
Command-line parameters control which dialogs are displayed, but they cannot change the sequence; the order of the dialogs is fixed.

Added later 2 h 54 min 44 s:
The described button-visibility logic only applies if dpi or language options are enabled. Otherwise, "Skip" is hidden, and "Next" and "Exit" are visible from the start.

Added later 3 h 36 min 48 s:
Explanation for the special case when "language" is enabled but "dpi" isn't: English users are likely to find that "Skip" button annoying. However, the hiding logic should be as described, because the "Skip" button also functions as a UI safety feature for users who don't understand the language.
In UI design, preventing a critical failure is always more important than reducing the number of clicks by one.

Added later 6 h 20 min 21 s:
"Interaction with the interface" is defined as any of the following:
- Changing the DPI value.
- Opening the language dropdown menu.
- Clicking the "Skip" button.
Clicks on non-interactive areas, such as the window background, do not constitute interaction.

Added later 10 h 21 min 14 s:
--- For a possible 120 DPI initial default :
The window size of 900px × 600px was estimated at 96 DPI. If the initial DPI is changed to 120 DPI, the interface elements must be packed more tightly, to ensure the initial window size still fits on low-resolution screens. Since it is difficult to estimate exactly how much space is required to pack all interface elements, the table below provides several options.
The left column shows the window size using the same metric as in the text above, and the right column shows the actual rendered size at 120 DPI, which must fit within the actual screen resolution if 120 DPI is the default.

+-----------------------+-----------------------------------+
| Base Size (at 96 DPI) | Target Rendered Size (at 120 DPI) |
+-----------------------+-----------------------------------+
| 800 x 580             | 1000 x 725                        |
| 720 x 560             |  900 x 700                        |
| 720 x 520             |  900 x 650                        |
| 640 x 520             |  800 x 650                        |
| 600 x 480             |  750 x 600                        |
+-----------------------+-----------------------------------+

Note that the described GUI fits comfortably even at 600 × 480 at 96 DPI, as the original 900 × 600 at 96 DPI was an overestimate.
Before proceeding with the UI design, both the default DPI and the minimum screen resolution must be decided.

Added later 12 h 19 min 52 s:
Here is the solution for 120 DPI that will make it work even on very small screens:
If the "xfce4-first-run" detects a screen resolution lower than 1280 × 720 (in any dimension), and the dialogue window does not fit on the screen, it will automatically reduce the current DPI to 96, and enable the "dpi" option so that the first dialogue is displayed. This behavior can also be modified through additional options in the config file.

Added later 12 h 34 min 46 s:
Based on all of that, I think the ideal dialog size is 720 × 500 @ 96 DPI, which equals 900 × 625 @ 120 DPI.
Or, the alternative option: cramp it all a bit into 576 × 400 @ 96 DPI, which avoids the need for a 96 DPI fallback, because it equals 720 × 500 @ 120 DPI.

Added later 21 h 53 min 56 s:
Here, I made a quick mockup at 576 × 400 @ 96 DPI:

Last edited by daffyduck (2026-08-04 08:39:02)

eriefisher · 2026-08-04 18:19:29

For me, I would likely dismiss your "wizard" right from the start as I am particular about my desktops and set them up for my usage. To each is own.

Also, I HATE when I'm asked "Are You Sure". If I wasn't I wouldn't have dismissed it. Forcing a user to jump through hoops enrages me. Do as I ask, no more, no less. This is part of the reason I left behind MS over 20 years ago.

Xfce Forum

Sub domains

#1 2026-07-29 23:53:35

Brainstorming: Improving Xfce's Out-of-the-Box Experience

#2 2026-07-30 06:42:13

Re: Brainstorming: Improving Xfce's Out-of-the-Box Experience

#3 2026-07-30 07:04:01

Re: Brainstorming: Improving Xfce's Out-of-the-Box Experience

#4 2026-07-30 07:20:08

Re: Brainstorming: Improving Xfce's Out-of-the-Box Experience

#5 2026-07-30 07:32:19

Re: Brainstorming: Improving Xfce's Out-of-the-Box Experience

#6 2026-07-31 10:57:58

Re: Brainstorming: Improving Xfce's Out-of-the-Box Experience

#7 2026-07-31 11:31:54

Re: Brainstorming: Improving Xfce's Out-of-the-Box Experience

#8 2026-07-31 11:48:17

Re: Brainstorming: Improving Xfce's Out-of-the-Box Experience

#9 2026-07-31 12:22:25

Re: Brainstorming: Improving Xfce's Out-of-the-Box Experience

#10 2026-07-31 13:57:30

Re: Brainstorming: Improving Xfce's Out-of-the-Box Experience

#11 2026-07-31 18:11:11

Re: Brainstorming: Improving Xfce's Out-of-the-Box Experience

#12 2026-07-31 22:38:12

Re: Brainstorming: Improving Xfce's Out-of-the-Box Experience

#13 2026-08-01 02:31:26

Re: Brainstorming: Improving Xfce's Out-of-the-Box Experience

#14 2026-08-01 09:14:34

Re: Brainstorming: Improving Xfce's Out-of-the-Box Experience

#15 2026-08-01 10:09:58

Re: Brainstorming: Improving Xfce's Out-of-the-Box Experience

#16 2026-08-02 00:34:59

Re: Brainstorming: Improving Xfce's Out-of-the-Box Experience

#17 2026-08-02 10:20:40

Re: Brainstorming: Improving Xfce's Out-of-the-Box Experience

#18 2026-08-02 10:36:04

Re: Brainstorming: Improving Xfce's Out-of-the-Box Experience

#19 2026-08-02 17:49:11

Re: Brainstorming: Improving Xfce's Out-of-the-Box Experience

#20 2026-08-02 19:54:04

Re: Brainstorming: Improving Xfce's Out-of-the-Box Experience

#21 2026-08-03 07:32:50

Re: Brainstorming: Improving Xfce's Out-of-the-Box Experience

#22 2026-08-03 07:59:40

Re: Brainstorming: Improving Xfce's Out-of-the-Box Experience

#23 2026-08-03 09:56:56

Re: Brainstorming: Improving Xfce's Out-of-the-Box Experience

#24 2026-08-03 18:56:08

Re: Brainstorming: Improving Xfce's Out-of-the-Box Experience

#25 2026-08-04 18:19:29

Re: Brainstorming: Improving Xfce's Out-of-the-Box Experience

Board footer