LLMs and xfwl4
I was planning to write a little about my usage of LLMs while building xfwl4 as a small section of a larger blog post, but I decided I’d rather get it out of the way on its own.
While LLM usage can be polarizing in the context of open source, I don’t really see it that way. It’s a tool, like any other. It has good parts and bad parts. On the bad parts, there are three things that stick out for me:
Training Data and Copyright
Among other sources, LLMs were trained on publicly-available data, without the permission of any of the rightsholders of that data. That especially smarts since I have a lot of open source code out there, much of it licensed under the GPL. Is training an LLM on my code copyright infringement? If someone gets output from an LLM that looks substantially similar to my code, and they don’t know and don’t follow my license terms, is that copyright infringement?
And if it goes the other way, if output I get from an LLM looks very much like someone else’s code, did I infringe on their copyright?
I’m not sure! US law seems to suggest that training is fair game, as long as the entity doing the training has legal access to the data they’re training on. As for the rest of it, I’m not sure that’s legally settled yet.
On top of that, it sometimes feels icky that companies like OpenAI and Anthropic are making money off of all this when all that data out there – for which they mostly paid nothing – makes it possible.
I don’t, however, think the best response for myself is to just pretend none of it exists. It’s a tool, and a useful one.
Environmental and Social Impact
LLMs need a lot of space, electricity, and water. Communities where data centers are being built, along with the associated power plant upgrades, are often getting stuck with some of the bill for those improvements, which is disgusting.
The secret deals between datacenter companies and utility companies, often with municipalities complicit, are often leaving regular ratepayers out to dry. That’s a local problem, and I hope those local people vote in representatives who will take better care of them.
Supply Chain
I don’t need to remind anyone how expensive GPUs and RAM are right now. I was planning to upgrade the mainboard in my laptop this year, which would require new RAM (my current board has DDR4 in it), but the cost of 64GiB of LPCAMM2 DDR5 makes my eyes water.
The consumer RAM market has been hollowed out; several companies have either stopped making consumer-grade RAM entirely, or have severely restricted supply in order to make more money selling to datacenters and AI labs. That’s capitalism at work for you, at the expense of regular folks who need to buy computing hardware for personal use.
But here I am, with a Claude Max 5x subscription for the past year and a half. I’m not comfortable with it, but the utility is just too great for me to take a principled stance here. I like it, and I want it, so I’m using it. Maybe that’s morally questionable, or worse. But, as I said: here I am.
xfwl4 and LLMs
So yes, I use Claude quite a bit while developing xfwl4. I don’t vibe-code, ever, and I probably use the LLM to generate less code than most people do. After all, building things with code is my hobby and passion (and I’m lucky I got to do it professionally for a quarter century), and driving an LLM is kinda boring.
Research and Planning
Most of my time with Claude Code is research and planning. One great match for LLM use here is helping me understand the finer details of xfwm4, since xfwl4 needs to duplicate all of its behavior. One common prompt of mine:
1 2 3 |
look at the xfwm4 source in detail and determine everything there is to know about $FEATURE. write up a plan for how to implement it in xfwl4 to notes/$FEATURE.md. |
I go do something else for a while, and when it’s done, I read the doc, and then spend a while asking Claude questions about it, and telling it the things I don’t like and what I’d like to be done differently, and it updates the doc.
Implementation
Most of the time I’ll start working from the notes doc myself, writing the implementation by hand. My guidelines for plan-writing to Claude are to do things in phases, and so I’ll complete a phase at a time, and then ask Claude to validate what I’ve done. Often, while I’m working, I’ll decide to deviate from the plan, and I’ll have to tell Claude to do the validation based on the outcome I want, not based on adherence to the plan.
Once it’s done, I’ll use /code-review and let Claude spawn sub-agents
to do a full review of the new code. This usually finds some problems,
even problems that the “main” Claude instance didn’t find during its
validation. I usually keep running /code-review again and again after
finding and fixing issues, until there aren’t any left. I actually
haven’t been doing /code-review for very long, maybe 6-8 weeks, as I
didn’t know about it. I wish I’d done it from the start, as it’s very
useful.
Sometimes I will have Claude write some code for me. Usually it’s when there’s a lot of boilerplate, or if there’s work that feels repetitive and tedious. Claude is generally a great fit for that, and I can both manually review the output and have a subagent do an independent review. I’ll usually keep CC in manual mode and approve every edit after reading it, but for some more mechanical changes, I’ll let it sit on auto for a while, and review when it’s done.
Occasionally I’ll have it write more substantial code for me, usually for bug fixes, and occasionally for small features. I find it does a pretty decent job here, but I keep it on manual mode and often ask it to write the code in a different way, or take a different approach.
Bug Fixing
Whenever there’s a bug, I’ll start looking into the code myself (I want to keep my debugging skills from atrophying), but in parallel I’ll also ask Claude to look into it, either by describing the problem, or pointing it to a Gitlab issue, if there is one.
I’ll admit that it’s rare for me to find the issue faster than Claude does, and there were some issues where I was completely lost, and Claude figured out something in 10 minutes that probably would have taken me days.
Tests
xfwl4 doesn’t have many unit tests, but I’d like to improve that at some point. Of the unit tests that do exist, they were al written by Claude. I’ve always found testing to be tedious, and never did a very good job of it. Claude’s tests are generally much more comprehensive than tests I’d write myself.
I’ve heard stories of people saying that Claude will change or delete failing tests instead of actually fixing the problem that makes the test fail, but that hasn’t (yet) happened to me.
xfwl4 also has a test-clients sub-crate that has a bunch of Wayland
and X11 client apps for manual testing of various compositor features.
I wrote the first Wayland test, using smithay-client-toolkit, but for
the rest of them, I told Claude to write them for me, using my first
test as a template.
My LLM Strategy
I don’t really have one. I just run the best model available for everything (Opus 5, at the time of this writing1). I don’t write skills or other bits of automation. I expect some of that is indeed valuable, but I’m just not interested in it, so I don’t do it.
My usage isn’t high enough to ever hit my 5-hour or weekly limits on the Max 5x plan, so I just don’t worry about it. I started out with the Pro plan, but very quickly started hitting limits in the first 1-2 hours of the 5-hour windows, so I eventually upgraded after trying out extra usage for a bit and deciding I’d be spending more going down that route.
As I said above, I don’t vibe-code. I care about code quality and about understanding what I’ve built. I care about being able to maintain it in the future, manually, without needing an LLM to do everything for me.
And That’s It…
That’s it, I guess. I don’t think I would have made anywhere near as much progress with xfwl4 without an LLM. It’s easily saved me months of time, not in writing code (for non-trivial things, I can usually write it just as fast or faster), but in tracking down problems and helping me figure out solutions, whether that’s in Claude reading and reasoning about my code to find something that’s wrong, or in adding tons of targeted debugging prints to gather the information we need, and then sifting through the log file for me to do analysis.
I know this blog post is a tiny drop in an ocean of people writing about their LLM use, but I expect some folks might be curious about the development process behind xfwl4, so I figured a sort of disclosure was in order.
It’s been a little over a month since the first preview release of xfwl4, and I’ve fixed many issues and added new features since then. Hopefully I should have a new preview release in the next week or so, but you can clone the git repository to check out the current state of things for yourself, whenever you want.
-
Yes, I know Fable exists. I was hesitant to start using Fable as it felt like Anthropic could pull the rug out and require API pricing for it at any time. It seems now they might leave it available to Max plan users indefinitely, but the usage terms (only allowing 50% of usage to go toward it) make me feel like I’ll get limit anxiety. ↩
Xfwl4’s First Preview Release
I’m pleased to announce the first preview release of xfwl4, Xfce’s Wayland compositor.
After close to six months of work, I feel like it’s ready to get some wider use, even though of course there will be bugs and missing features. Think of this as an alpha release.
First off, I’d like to give a big thanks to the rest of the Xfce core team for offering to sponsor this work. I’ve been an on-again off-again Xfce developer since 2004 (more “off” than “on”, I suppose), and I consider it a great privilege to have this work sponsored, giving me the opportunity to focus solely on this project since the beginning of the year. This is also a huge thank-you to all the supporters who have generously donated to Xfce over the years.
Here are the essentials:
Source tarball. Build and install instructions are in the README. Please pay careful attention to build and runtime prerequisites.
Issue tracker. Search the issue tracker first in case someone else has already filed a similar issue. If not, and you file a new one, be sure to fill out every part of the issue template.
Git repository. If you’ve
found an issue, it would be helpful if you could ensure it’s still
present on git main. You can also try any fixes and features I’ve added
since the release. Be sure to clone it with --recursive.
The end goal of xfwl4 is to behave as closely as possible to an Xfce desktop running on an X server. Ideally a user could switch between the two without even knowing there’s a difference. In reality, of course, it won’t be quite that seamless, and there’s still more work to be done to get as close as possible to that ideal. This is a first solid cut at it, at the very least.
The issue tracker will give you a decent idea of things that are not implemented yet or are known to be broken, but here is a list of notable things that won’t work, so you aren’t surprised:
- The “Mouse and Touchpad” settings dialog (but whatever settings you’ve set under X11 will be applied under xfwl4) (issue).
- The “Workspaces” settings dialog (issue).
- Screen margins (issue).
- xfdesktop’s minimized window icon view, and the middle-click window menu (issue and issue).
- Pager thumbnails in the panel (no tracking issue yet).
- Taskbar apps can only change maximize/minimize/fullscreen state (issue and issue).
- Keyboard shortcuts for application/application-window switching (regular all-window cycling works fine) (issue).
- Most (all?) apps will not be able to restore their window positions or workspace on startup (issue and issue).
(This is not an exhaustive list, just a few things I thought worth calling out.)
Over the coming weeks and months, I plan to write a blog series on how I built xfwl4. I’ll update this to link each new post here as they’re published. Anyhow, give it a spin!
Xfwl4 – The roadmap for a Xfce Wayland Compositor
Jan 27,2026
Xfwl4 - The roadmap for a Xfce Wayland Compositor
We, the Xfce team are excited to share some great news!
After careful consideration, we’ve decided on a meaningful way to use the generous donations from our community: funding longtime Xfce core developer Brian Tarricone to create xfwl4, a brand-new Wayland compositor for Xfce.
This initiative will utilize a significant portion of the project’s donated funds, but we believe it’s an important investment in Xfce’s future.
The goal is, that xfwl4 will offer the same functionality and behavior as xfwm4 does, or as much as possible considering the differences between X11 and Wayland. Using xfwl4 should feel just like using xfwm4 on X11. We even plan to reuse the existing xfwm4 configuration dialogs and xfconf settings to ensure a seamless transition.
Xfwl4 will not be based on the existing xfwm4 code. Instead, it will be written from scratch in rust, using smithay building blocks.
Why doing a rewrite?
The first attempt at creating an Xfce Wayland compositor involved modifying the existing xfwm4 code to support both X11 and Wayland in parallel. However, this approach turned out to be the wrong path forward for several reasons:
- Xfwm4 is architected in a way that makes it very difficult to put the window management behavior behind generic interfaces that don't include X11 specifics.
- Refactoring Xfwm4 is risky, since it might introduce new bugs to X11. Having two parallel code bases will allow for rapid development and experimentation with the Wayland compositor, with zero risk to break xfwm4.
- Some X11 window management concepts just aren't available or supported by Wayland protocols at this time, and dealing with those differences can be difficult in an X11-first code base.
- Using the existing codebase would require us to use C and wlroots, even if a better alternative is available.
Why to base xfwl4 on smithay?
Once the decision to write a compositor from scratch was done, the next major question was: Which Wayland support library to use as a base? In order to find an answer on that question Brian evaluated wlroots and smithay. The decision to use smithay as a base was done for the following reasons:
- smithay supports most/all official Wayland protocol extensions, as well as the wlroots protocols and some KDE protocols.
- smithay has no high level abstraction, as wlroots has. However, it allows for very deep customization of the graphics and input pipeline, as well as all aspects of Wayland protocol and desktop/shell handling.
- smithay has great documentation.
- Using rust makes it easier to avoid memory related bugs and decreases the chances of crashes, something that should never happen for a Wayland compositor.
- Rather subjective: Brian has a strong preference to write code in rust over writing code in C.
- wlroots is written in C, in a way which makes it very difficult to write wlroots rust bindings.
Scope of the project
Besides getting feature parity with xfwm4, the xfwl4 project scope includes as well some other related tasks:
- Major changes to session-startup will be required, since on Wayland the compositor has to be the root of the session instead of xfce4-session.
- Support for the xdg-session-management protocol is another goal.
- As well support for XWayland is part of the roadmap.
- The build system of the Xfce CI container will need to be upgraded in order to support building rust code via meson.
Brian has already started work on the project, so stay tuned for the first development release of xfwl4, which we hope to share around mid-year.
If you’re interested in the detailed reasoning behind the project or want to explore all the technical details, check out the issues and the work in progress source code.
For any questions related to xfwl4, please visit our Matrix channel #xfce-dev.
We’d like to extend our heartfelt thanks to our generous supporters on Open Collective US and Open Collective EU for making this project possible!
Best regards,
The Xfce development team
Xfce 4.20 Released
Dec 15,2024
Xfce 4.20 released
After almost two years of work, we are happy to announce the release of Xfce 4.20.
Since Xfce 4.18 a lot of major development happened. Our team added many nice new features, did a gazillion of bug fixes and did various minor improvements. Finally, all that was released for your pleasure.
The major focus during this development cycle was the preparation of the codebase to be ready for Wayland. So that we meanwhile have experimental Wayland support for most components. More details in the 'Wayland' section below.
Assuming you have installed Xfce 4.18, here an overview on the major changes you will see on an upgrade to Xfce 4.20.
General
Wayland
Important Notice: Please be aware that the Wayland support in Xfce 4.20 is experimental. It is recommended for advanced users only, as you may encounter bugs and experience incomplete functionality. Proceed with caution!
Thanks to Brian and Gaël almost all Xfce components are able to run on Wayland windowing, while still keeping support for X11 windowing.
This major effort was achieved by abstracting away any X11/Wayland windowing specific calls and making use of Wayland/Wlroots protocols. A whole new Xfce library, "libxfce4windowing" was introduced during that process. XWayland will not be required to run any of the ported Xfce components.
So far Xfce does not feature a compositor which supports Wayland. If you want to run Xfce in Wayland, Labwc and Wayfire will give you the best results. A detailed instruction on this can be found here. Please be aware that Wayland support is still experimental!
Plans are underway to add Wayland support to Xfwm4 while preserving its existing X11 functionality. However, such a restructurization will be a major effort and we cannot tell yet when/if it will be done, so please don't hold your breath waiting for it.
For few components and multiple features, it was not possible to port them to Wayland, partly because there are no standardized Wayland protocols available yet to provide the required services:
- Workspace support is missing (ext-workspace protocol was just merged).
- Systray icons will be missing for multiple applications (required to use StatusNotifier instead of GtkStatusIcon)
- Xfce4-settings: Keyboard and mouse settings so far are internal to the Wayland compositor and as such the according Xfce dialogs won't be available on Wayland yet.
- Power related keyboard handling (brightness keys, suspend, etc.) is internal to the Wayland compositor and as such cannot be supported yet by Xfce components.
- Wayland does not specify a native protocol for taking screenshots. However, xfce4-screenshooter already supports screenshots via the wlroots 'screencopy' protocol (entire screen). Screenshots of a rectangle selection or the active window are not yet supported via Wayland.
Some other Xfce components don't run at all on Wayland:
- Xfwm4
- Xfdashboard
- Xfce4-screensaver (porting to Wayland completed but not merged, as it requires the experimental libwlembed library)
- Xfce4-windowck-plugin (needs to be ported to libxfce4windowing)
- Xfce4-xkb-plugin (keyboard handling is internal to the Wayland compositor)
More detailed info on the current Wayland status can be found on our Wayland roadmap.
Scaling
Icons and thumbnail scaling was fixed for various components. Various missing icons for larger scales were added. Any blurriness when using Xfce components on a HiDPI display should be gone now.
exo
Icon View Performance
By using different container types, the "Exo-Icon-View" now can handle 100,000 files and more without freezing.
Type ahead search box
The type ahead search box in the exo icon view now always stays inside the according view widget.
libxfce4ui
Shortcut Editor
Shortcuts now can be used for multiple actions if they don't conflict with each other.
About Dialog
The dialog now shows the distribution logo, information about the used windowing system and the used GPU.
libxfce4windowing
This library is new to Xfce. Libxfce4windowing is an abstraction library that attempts to present windowing concepts (screens, top level windows, workspaces, etc.) in a windowing-system-independent manner.
Currently, X11 is fully supported via libwnck. Wayland is partially supported by using various Wayland protocol extensions. However, the full range of operations available on X11 is not available on Wayland, due to missing features in these protocols extensions.
thunar
Mounted and Remote Locations
Mount points now show an emblem and have a specific type description.
Ipv6 remote URLs are now supported.
It is now possible to create symbolic links as well on remote locations./p>
Search
It is not required any more to wait until a search is finished to open the context menu on search results.
Toolbar
A couple of new toolbar buttons were added:
- View Switcher - A drop-down button to select a view.
- Menu - This hamburger button will show automatically in the toolbar, when the menubar is hidden. It will reveal a vertical menu, bar, when pressed.
- New Tab - Open a new tab using the current directory.
- New Window - Open a new window using the current directory.
On shrinking the Thunar window, toolbar items will now be moved to an overflow menu. Like that, it is possible to maintain smaller thunar windows.
Furthermore, a bug was fixed which prevented the usage of submenu custom actions in the toolbar.
Window Decorations
There is now an option to use client side decorations in Thunar (CSD).
Statusbar
An option to show the number of hidden files in the statusbar was added.
Recently Used Files
Only files which were successfully opened are now added to the list of recently used files.
Directories won't be added to the recently used files anymore.
Symbolic Icons
There is now an option to use symbolic icons in the side pane and colored icons in the toolbar.
Drag and Drop
While dragging files, folders are now opened automatically on hover.
While dragging files, the focus of the split view pane is now updated when hovered.
Performance
In the past, you might have faced situation involving bigger numbers of files in which thunar showed a freeze. Due to various different performance measures, thunar now is much more bullet-proof for action involving huge numbers of files.
This was achieved by using appropriate container types, moving some actions into separate jobs and throttling of view-updates.
A number of integration test cases will be used in order to keep performance on the current level in the future.
Custom Actions
Shortcuts for custom action will now as well work when the custom action is located in a sub-menu.
File Transfer
For file validation in thunar 4.18.x a md5 checksum was calculated for source and target file. This calculation turned out to be rather slow and actually superfluous. Now files are just compared directly. In addition, the usage of direct I/O operations now attempts to prevent comparison of possibly cached buffers.
An option was added to only copy files in parallel if the relevant devices are in idle state. This prevents possible fragmentation during copy for HDD drives.
Transferring files no longer steals the current focus.
The file transfer question dialog now provides the same options while having less buttons. In addition, file thumbnails now are properly requested by the dialog.
Launchers
By default, launcher names instead of filenames are shown now for trusted launchers.
Undo/Redo
The user now will be asked before any deletion will be done by an undo operation.
List View
Similar to the tree-view side pane, the main view now also supports folder expansion.
Split View
A shortcut now can be used to toggle between split-view panes, and the focused pane now uses different coloring.
A dialog will now ask for confirmation when closing a split-pane with multiple tabs.
xfce4-appfinder
The application list now as well can be navigated via Ctrl+N / Ctrl+P keys (VI default).
An option was added to close the Appfinder window automatically when focus is lost.
Ctrl+Enter can be used to execute commands immediately when selecting entries from the dropdown.
Within the new version, application specific actions will show on right click.
An option to show generic names of launchers was added.
Appfinder optionally can now be launched as a daemon, so that it will respond even quicker.
An option allows now to launch items on a single click.
xfce4-panel
General
The border width of the panel is now configurable.
For manual installations: the panel now does its best to find plugins in XDG base directories, and better preserves its configuration when it can't find them.
Clock
LCD clock: An option was added to visualize inactive segments.
Analog: There is now an optional 24h mode.
Digital: Week numbers now are shown optionally.
Show Desktop
There is now the possibility to show the desktop when hovering the mouse on the "show desktop" panel icon.
Tasklist
Icon size management has been improved overall, notably by switching to libxfce4windowing.
Preferences
The 'delete' key can now be used to remove panel objects, and several objects can be removed at once.
Panel objects in the panel configuration list now will have the same icons as in the panel itself.
xfce4-power-manager
Screen Locking
There is no dedicated "security" tab anymore. Lock screen management was massively simplified and "Light Locker" was dropped. "lock-on-sleep" is now synchronized with xfce4-session and xfce4-screensaver.
Screen locking settings are now only handled by xfce4-screensaver to avoid conflicts. A button to open xfce4-screensaver-preferences was added:
Power Settings
Support for handling different power profiles via power-profiles-daemon was added.
The overall charge state calculation was wrong for some cases and is now fixed.
When the critical power dialog pops up, unintentional user actions are now prevented.
There is now support for the hybrid sleep mode.
The device details tab now as well shows the energy rate.
Others
Several use-cases for lid close were fixed.
There are now the options "shutdown" and "do nothing" on lid close.
Buttons to change the brightness exponentially and keyboard backlight toggle keys now are supported.
xfce4-session
The logout dialog will not provide a checkbox to enable session saving anymore.
It is now possible to start a Wayland session via 'startxfce4 --wayland'.
Minimal support for xdg-desktop-portal was added by registering for a wallpaper, screenshot and background xapp.
xfce4-settings
Appearance Settings
Icon themes are now loaded in a separate thread, in order to prevent a possible freeze.
For icon themes which are known to be incomplete, a warning now will be shown.
The usage of client side decorations is opt-in now, not opt-out.
Dark themes now are identified and supported in a more reliable way. (Relevant e.g. for the Qogir and Orchis themes)
´Display Settings
The default display profile has been added to the list of profiles that can match, and will be used if more than one matches now.
Profile management has been extended to all profiles, not just those that match, and their names can now be edited.
Scaling now always is done for both dimensions, and the preview shows the resulting size.
Mirror state management has been improved overall, in particular by removing the need to match refresh rates.
The minimal dialog has been improved, in particular by allowing the display to be extended to the left and from top to bottom, and with compact profile display.
Mouse Settings
A checkbox was added to toggle between adaptive and flat mouse accel profile.
High resolution scrolling can now be enabled for mice which do support it.
Mime Settings
It is now possible to select/change multiple items at once.
xfconf
A systemd user unit, corresponding to the D-Bus session service, is now added.
Whitespaces are now properly escaped when writing a xfconf channel to disk.
Xfconf-query now displays array contents.
xfdesktop
Background Management
For random wallpaper cycling, wallpapers now are only repeated after all other wallpapers were shown.
Old Xfce backgrounds were ported from .png to .svg to be usable for large screens.
Gradients will now be rendered in a gamma-correct way.
Icon grid
The confirmation dialog for arranging desktop icons now is optional.
It is now possible to set custom colors for icon labels and icon background.
The icon grid on each monitor is now independent of one another.
Minimized Application Icons
Window icons are now initially shown on the monitor where the window was present before being minimized.
The context menu (when clicking on an empty space) now has more useful options than before.
File Icons
There is now an option to sort folders before files.
The positions of the icons are now saved in a way that should avoid icons moving around in unexpected ways when monitors are added and removed.
New files and dropped files now will be placed near the current cursor location.
Icons of fixed disks and drives can now be optionally shown.
Preferences
The 'Desktop Icons' tab was fully reworked.
All shortcuts of Xfdesktop now can be configured, using the XfceShortcutsManagers widget.
More folders that hold background images were added as shortcuts in the settings dialog.
The settings dialog will update if the background is changed from outside the dialog.
Wallpaper image folders now are loaded fully asynchronously to prevent lag.
Context Menu
Cascading custom actions will now as well shown correctly in Xfdesktop.
It is now possible to open multiple selected folders at once.
The context menu now opens on button press rather than button release, as most users will expect.
The middle-click window list menu has new styling and added features.
xfwm4
Support for stretch theme variants
compositor: Block softpipe for GLX vsync
focus: Include skip taskbar/pager when passing focus
Fix crash when alt-tabbing (#762)
For the sake of readability, this list only shows main highlights. Check the full Xfce 4.20 changelog for a more detailed list of changes.
The theme "Greybird-dark" and the icon-theme "elementary Xfce dark" were used for the screenshots. This summary can as well be viewed as a localized online tour.
This release can be downloaded here, either as a set of individual packages or as a single tarball including all individual versions.
Our Sponsors
Thanks go to Gandi for providing the Xfce server infrastructure for free, and to Kalmar NDC for sponsoring our GitLab runners. We appreciate your support!
As well, many thanks to our generous financial supporters on Open Collective US and Open Collective EU!
At the moment, aside from the couple of hardware purchases for our developers, we don't have specific plans for the funds. We are exploring the best ways to use them effectively. It's reassuring to know we have such strong financial backing. Thank you for your support!
Best regards,
The Xfce development team
Xfce 4.20 Pre2 Released
Dec 01,2024
Xfce 4.20 Pre2 Released
Dear Xfce community, I am happy to announce the release of Xfce4.20 pre2.
This platform pre-release consists of the Xfce core components and will be followed by the final Xfce4.20 release soon. We fixed some quirks which were found in Xfce4.20 pre1, did some further polishing and the result is now released as Xfce4.20 pre2.
Early adopters are invited to give it a try and check for compatibility before the final release, which is planned for 15. December.
Xfce4.20 pre2 includes all Xfce core components. The tarballs for building it can be found here:
Though, you might prefer to wait for distribution specific development packages.
Wallpaper contest
It is a pleasure for me to present you the outcome of our Xfce4.20 wallpaper contest, which received numerous nice wallpaper submissions.
This year we received 54 submissions in total, contributed by 18 different users.
Since two wallpapers were tied for the third place, four new wallpapers will be shipped with Xfce-4.20.
The winner wallpaper, which will be the new Xfce4.20 default wallpaper, was brought to you by "kaz sb":
The second place, authored by Denys DEKUVE:
The third place, authored by Farhang Bakhshi:
And another third place, authored by Rose Pierce:
You as well might be interested in the complete list of submissions.
Coming soon
A detailed sum up of all new features in Xfce4.20 is planned for the final release, so stay tuned!
Best regards,
The Xfce development team
Wallpaper Contest for Xfce 4.20 open for voting
Nov 15,2024
Wallpaper Contest for Xfce 4.20 open for voting
The submission phase for the Xfce 4.20 wallpaper contest is over now, and I am very happy to see numerous contributions.
While writing this blog post, 47 different wallpapers were submitted by 15 different authors.
Whatever will be the outcome of the contest, I would like to express my thanks to all these authors and wish all of them good luck for the voting period.
Starting by now, two weeks of voting will show which wallpapers are the most popular ones.
In order to cast your vote, login at gitlab.xfce.org and add a ❤️ reaction to all wallpapers you want to upvote. (Other emojis will not be counted)
Remember to vote for the best wallpaper, not just the best image. For instance, it's beneficial to provide free space for desktop items.
Voting will be closed on 29. November. Like that, the new wallpaper can be utilized for the Xfce4.18 pre2 announce, which is planned for beginning of December.
Happy voting !
Xfce 4.20 Pre1 Release and Wallpaper Contest for Xfce 4.20
Nov 01,2024
Xfce 4.20 Pre1 Released
Dear Xfce community, I am happy to announce the release of Xfce4.20 pre1.
Xfce 4.20 Pre1 is a platform pre-release, which gives early adopters the possibility to test the new release and to check for compatibility.
Further implications for the pre1 release:
- In order to increase stability, no new features will be added to Xfce core components until the final release.
- We will not add new strings either, in order to give translators the possibility to reach a complete translation for the final release.
A detailed overview on the major changes introduced in Xfce4.20 will be given for the final release, planned for December 15th.
Xfce4.20 pre1 includes all Xfce core components. The tarballs for building it can be found here:
Though, you might prefer to wait for distribution specific development packages.
Wallpaper Contest for Xfce 4.20
Like for Xfce 4.18 I would like to ask the Xfce community to contribute a few wallpapers. Everyone will have the opportunity to vote on them to elect the new default wallpaper for Xfce 4.20.
If you possess the required skills, your contribution would be greatly appreciated!
Like the old Xfce wallpapers, the new wallpaper should be a vector graphic with an unmodified Xfce mouse on it and some fancy shapes.
Note that the image must be all yours and needs to be licensed under CC BY-SA 4.0. If you do not specify a license in your post, then we will assume that you are licensing the image under the CC BY-SA 4.0.
The image should not mention the software (FOSS or proprietary) used to create the wallpaper in the metainfo.
The deadline for submissions is the 15th of November. Like that, we will have two weeks left for voting and integration of the new wallpaper into the Xfce pre2 release.
In order to participate, take a look at the Xfce wallpaper contest GitLab issue.
Please note that this year only the ❤️ emoji will be considered as an upvote, in order to simplify vote counting. You can upvote as many wallpapers as you like.
My journey to a new laptop enabled by Xfce donations
I have been contributing to Xfce since about 2013. Over the years, computers have come and gone, from netbooks to desktops to laptops. Since I moved to another country, I’ve been avoiding owning a desktop for practical reasons - the less bulky my belongings, the better. Before the move, I decided to sell my aging desktop (self-built) and even older laptop (a Dell Vostro - ah, fond memories of playing GTA V at 20 FPS) for peanuts and invest in a gaming laptop.Xfce is moving from IRC to Matrix
Apr 23,2024
Xfce is moving from IRC to Matrix
After a 6-month trial period, as of April 1, 2024, Xfce moved its official communication channels from IRC to Matrix.
The old IRC channels will remain open, so you can still hang out there. However, the 'official' channels linked in the Xfce Wiki now will be the Matrix channels.
This change affects the following channels:
- #xfce on libera.chat --> #xfce:matrix.org -- general user support and discussion
- #xfce-dev on libera.chat --> #xfce-dev:matrix.org -- development discussion
- #xfce-commits on libera.chat --> #xfce-commits:matrix.org -- notable GitLab activity
Reasoning
In the past, it was possible to connect and idle on libera IRC channels via Matrix.org bridge. Using Matrix to connect is very convenient for several reasons:
- When accessing IRC channels via Matrix bridge, it's not necessary to manage an IRC bouncer. Bridged Matrix channels retain messages that arrive while you are offline.
- Chat history is synchronised across multiple devices by default. No special BNC setup is required.
- Based on personal experience, the entry barrier for Matrix seems to be lower than for IRC.
- On IRC, after answering a support question, you might realize that the person asking it went offline hours ago (no BNC used) and as such you wasted your time. Won't happen if the question was raised by a Matrix user.
As such, several people started connecting to the Xfce IRC channels via Matrix (including myself). However, on July 2023, the party was over. Libera.Chat decided to disable Matrix bridging and suggested to use so-called "channel plumbing" until further notice. I'm not sure about the technical details here, but in the end, "plumbing" did not work out for some reason. By November 2023 it became clear that bridging would not come back either.
Meanwhile, Xfce communication became fragmented. Some people dusted off their IRC bouncers and used them again, some used a private Matrix server setup (Heisenbridge was still functional) and some just stayed on the Matrix channels, which were no longer interconnected to the IRC channels.
In order to end that fragmentation and because of the above mentioned Matrix advantages, after 6 months of testing and adding some Matrix bots (real nice job Brian!), the Xfce team decided to prefer Matrix over IRC in the future and settle down there.
So, even if you are a hardcore Xfce IRC user, please install the Matrix client of your choice and give the shiny new (cough) possibilities offered by Matrix a try. Looking forward to see you in the Xfce Matrix channels!
An Estimate on the Total Number of Xfce Users
Apr 06,2024
An Estimate on the Total Number of Xfce Users
Recently, my wife asked me how many people in total actually use the software I develop in my free time (mostly thunar).
I never thought about that question, so I just made a wild guess. Based on the number of people I believed are active on the Xfce Matrix / IRC channels, I answered: "... maybe between 2000 and 10.000 people do use Xfce".
I know nobody can give exact numbers. It's all about package downloads, OS types reported by browsers, and other more or less biased data harvesting.
However, the question nagged me, so I searched for some more reliable numbers.
Ubuntu came to my mind. Since it collects some user-data, I thought it might be a good starting point for my investigation.
Via web search, I found out that there seem to be about 40 Million Ubuntu users.
According to this post, 15% of them use Xubuntu.
--> 6 million Xubuntu users (holy crap)
Further digging revealed that aproximately 33% of Linux desktop users use a Ubuntu based distro.
--> Approximately 120 million Linux desktop users in total
--> Considering a rather conservative estimate of 10% Xfce users on non-Ubuntu systems --> another 8 million installs
That would be approximately 14 million Xfce users. So many people do use the software I tinker with? /o\
Considered that estimate is more or less accurate, than why are the Xfce communication channels rather calm?
For example, we currently have around 6000 non-blocked accounts at gitlab.xfce.org. That would be roughly one in every 2000 users (0,043%) who create an account. Can that be true?
Since I was not sure if my numbers are reasonable, I asked for feedback in the Xfce forums.
The estimate seems to be mostly fine. On the question about the rather low percentage of people who get in contact via official Xfce communication channels, there are several guesses:
- If users are looking for answers to Xfce related problems, most of them search/ask on Reddit, Stack Exchange, ChatGPT, etc., or in distro specific channels.
- Xfce is a very stable DE. Many Xfce users probably don't try to get in contact because things just work fine for them.
- Many people might just use software "as is" and don't even bother to ask for any advice.
I wanted to share this estimate with you, since for me, it was a surprise to see that such a huge number of people actually seem to use Xfce. Knowing so gives me even more motivation to further improve Xfce.