LLMs and xfwl4

• July 28, 2026
• Brian Tarricone | Xfce

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:

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 writing¹). 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.

Xfwl4’s First Preview Release

• June 21, 2026
• Brian Tarricone | Xfce

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

• January 27, 2026
• Alexander Schwinn

Xfce 4.20 Pre1 Release and Wallpaper Contest for Xfce 4.20

• November 1, 2024
• Alexander Schwinn

My journey to a new laptop enabled by Xfce donations

• June 12, 2024
• André Miranda

Xfce 4.18 Pre2 Released

• December 1, 2022
• Alexander Schwinn

Dec 01,2022

Xfce 4.18 Pre2 Released

Dear Xfce community, I am happy to announce the release of Xfce4.18 pre2.

This platform pre-release consists of the Xfce core components and will be followed by the final Xfce4.18 release soon. We fixed some quirks which were found in Xfce4.18 pre1, did some further polishing and the result is now released as Xfce4.18 pre2.

Early adopters are invited to give it a try and to check for compatibility before the final release, which is planned for 15. December.

Xfce4.18 pre2 includes all Xfce core components. The tarballs for building it can be found here:

• Download individual tarballs
• Download one tarball which includes all releases

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.18 wallpaper contest, which received numerous nice wallpaper submissions.

The winner wallpaper, which will be the new Xfce4.18 default wallpaper, was brought to you by Katerina Shkel:

The second and third place both go to Denis Kuzminok. As well these wallpapers will be shipped within Xfce:

You as well might be interested in the complete list of submissions !

Coming soon

A detailed sum up of all new features in Xfce4.18 is planned for the final release, so stay tuned!

 

Best regards,

The Xfce development team

GSoC’22 – [Part 2] User Profiles in Xfce-Terminal

• October 23, 2022
• Amrit Borah

User-Profiles in Xfce-Terminal

Note: This feature has not yet been merged. The UI/UX have been finalized but there are some internal implementations that are being reviewed.

The Task

Work Left

GSoC 22 – The Closing Blog Post

• October 21, 2022
• Pratyaksh Gautam

In the summer of 2022, I participated in Google’s Summer of Code, contributing to the Thunar file manager at XFCE, with the help of my mentor Alexander Schwinn. It’s been about a month since my GSoC term was officially over, and after a hectic couple weeks, I’ve finally decided to sit down and write down the closing blog post.

New features in Thunar

I’ll start off by introducing the features that I worked on, and a rough idea of how the implementation for the same works. Of these, undo-redo and file counts for folders are already merged on master and have been released with Xfce 4.18. The tour probably does a much better job than I will here, so be sure to go through it as well!

Undo-redo

This is the big one. While adding support for undo and redo, one of the most crucial things for me was doing it in an elegant way that would make it easy to have multi-level undo and redo.

How we decided to do this was to maintain a global linked list, containing information about the last performed operation, including what type of an operation it was, what files were involved in it, etc. This allowed it to be as trivial as moving a few pointers around to keep track of the state of the system once an undo or a redo is performed. The actual undo/redo operation is simply executing either the inverse of the last performed operation, or executing the exact same operation that was last undone.

I’m of course glossing over a lot of the details that made this a fair bit harder than we had initially anticipated. Nonetheless, with some help from Alex, we were able to ship this in time for the 4.18 release! :raised_hands:

File counts for folders

Adding file counts for features was just a little addition to help better utilize the ‘size’ column for folders, which was essentially wasted space earlier.

It was essential to be asynchronous with its implementation, which turned out to be a bit trickier than I had initially expected. It mostly boiled down to a line of conversions between file abstractions that I had taken for granted would have a low overhead (spoiler alert: they did not have a low overhead).

Gallery view

I was less than confident when first approaching Gallery view, since I thought I’d have to create an entire view from scratch. Luckily, that really wasn’t necessary. I was able to make a new view based off the same abstract view class that the existing icon view used. This is probably better for multiple reasons, since building on existing things makes for much simpler design for the new additions, and easier code review as well.

While I initially had envisioned a masonry image gallery, like the kind you would see on sites such as Pinterest, the abstract icon view lent itself much better to a square icon based gallery, similar to what most Android phone galleries have by default these days.

The gallery view PR is not yet merged into master, needing a few minor fixes on the dialog tooltips (which I’ve sadly been a bit too busy to work on yet), before it’s completely ready.

Not all smooth sailing

While I had initially hoped to complete what I had mapped out in my GSoC proposal in my summer vacations itself, that didn’t work out as intended. Once my semester at college started, I started struggling a bit to balance my academics and my GSoC commitments, but I was steadily making progress.

GSoC being flexible with its contributor timelines this year was an absolute life-saver, since I had to extend my deadline multiple times in order to hit the milestones on my proposal.

The lowest point was when in the midst of all this, some personal family issues cropped up and I essentially went incommunicado for almost a week. This would’ve been enough to fail my proposal in some organizations, but Alex still gave me a chance to make up on lost time when I was back, and for that I’m incredibly grateful. I was able to capitalize on this opportunity and get plenty of work done, though it was really quite hard (and probably not very good for my health long term :sweat_smile:).

Advice for others

I recently received an email from someone who was looking to contribute to XFCE in this year’s GSoC, and wanted some advice. I’ll relay part of what I wrote back over here:

I’d say the most important thing is to dive into it while still knowing that you don’t know anything :P

Try at a problem with your intuition for what might work. If you get stuck, push for another 15-20 mins and note down what you try. In this time you should be consulting documentation, StackOverflow, Github issues etc.
If you still aren’t able to figure it out, send a message on the XFCE IRC/Matrix channel, and be descriptive about what you tried, why you think it should work, and why you think it might not have worked. The mentors are incredibly helpful, and you’ll often get an answer that will deepen your understanding of the system and coding in general.

In addition, I’d also like to stress that communication is key!. Your mentors are there to help you, and they want nothing more than a successful and productive summer for the both of you. Raising issues that you’re facing as early as you can allows the both of you to think about and discuss how to tackle them.

Acknowledgements

I’m incredibly grateful to my mentor Alexander Schwinn, who is one of the most helpful people I’ve had the pleasure of working with. He’s been incredibly kind and polite, more than one could reasonably expect out of anyone given the circumstances.

I’m also very thankful for all the help I’ve received from the dedicated XFCE community, including Sergios Kefalidis, Yonghwa Hong, Gaël Bonithon, and many others.

Finally, I’d like to thank Google Summer of Code for the wonderful opportunity, which has definitely been a fantastic hands-on learning experience for me.

GSoC’22 – File Highlighting in Thunar

• August 13, 2022
• Amrit Borah

About the feature

• The aim of this feature is to enable the user to highlight files/folders across the various different views.
•  The feature can be toggled on/off through the View Menu.
•  The highlight color can be selected by navigating to the Highlight tab in the properties dialog of the respective file. The properties dialog can be brought about by selecting the Properties option under the Context Menu  (Right click on the desired file/folder to show the context-menu)
  

Requirement: GVFS (Gnome Virtual File System)

 Implementation

• The biggest challenge was figuring out how to paint the highlights on the various different views.
• The solution was to use a GtkCellLayoutDataFunc that is called on each item of the view. This way we can set the specific background color in the CellRenderer for each of the different items on view.
• Another challenge that came up was implementing the rounded corners.
• For this, modifications were made to the IconRenderer & a new custom TextRenderer was introduced. The trick was to use cairo to clip the backgrounds & paint the specific color.

 This feature is possible with the support by Thunar's lead developers - Alexander Schwinn (alexxcons), Sergios - Anestis Kefalidis (SKefalidis) and Yongha Hwang (MShrimp4).

GSoC 22 – The First Blog Post

• May 28, 2022
• Pratyaksh Gautam

I’m really looking forward to this summer, since my project proposal for this year’s Google Summer of Code has been selected! I’ll be working on adding features to Thunar file manager, an XFCE application, with the help of my mentor Alexander Schwinn.

My history with XFCE

I’ve been big on open-source ever since my school days, and actually ran Xubuntu (an Ubuntu distribution with XFCE as its desktop environment) on my daily driver, an old netbook back in eleventh grade. It was too slow of a device to run GNOME, so I absolutely had to use a lighter-weight desktop environment, and compared to alternatives like LXDE which I didn’t like the aesthetics of, and pantheon (the default DE for elementaryOS) which still felt lacking in terms of performance, XFCE was the perfect balance of form and functionality.

Since then, I’ve done some distro-hopping before settling on my current setup, hand-rolled with awesome window manager and no DE. While I generally prefer to use the command-line, Thunar has been by GUI file manager of choice ever since I started using this setup a little over 2 years ago. It’s fast, light-weight, and gets the job done without getting in your way, which is exactly what I need.

Planned features

Thunar does however lack a few features that would be really handy to have, which is exactly what I’ll be working on.

Undo-redo

Adding undo and redo is an absolute no-brainer for me, and would probably be the single biggest thing I think Thunar is currently missing. If you’re anything like me, you’ve often selected the wrong file to move into another directory, and you have to manually undo it and move the correct file once you realize your mistake. Implementing this would do away with such frustrating tedium in the case of minor mistakes.

File counts for folders

Currently, the list view in Thunar has a ‘size’ column which shows the size of the corresponding file in the listing. However, this column is blank for folders (or directories). As such, it’s essentially wasted space for directories, but it could be put to good use showing the count of the files in the folder instead.

Picture-specific maximized thumbnail view

Managing pictures is primarily based on the content of the picture itself, rather than metadata like the name, date etc. So it would be very convenient to have a specific view optimized for folders with a large number of pictures, where the thumbnails take up as much space on the screen as possible. Think Pinterest, Google images etc.

If somehow I complete the work enlisted in my proposal ahead of time, I plan on looking at some of the file system synchronisation bugs that some Thunar users have reported.

Conclusion

I’m glad to have the opportunity to be able to work on open-source tools I myself use everyday, and feel really lucky to have the support of Google to be able to work on this over this summer. I’m really grateful for the help I’ve gotten along the way to getting my proposal accepted from Sergios Kefalidis, Alexander Schwinn, and other members of the XFCE community.

I’d like to congratulate my fellow XFCE GSoC contributors Yogesh Kaushik and Amrit Borah as well (who coincidentally are also from different IIITs :grin:).