Concerns Regarding the Choice of Rust for the Xfce Wayland Compositor

[Brian Tarricone]

Hi Theron,

(Seems you dropped xfce4-dev from the mailing list.  Didn't notice before sending you my reply, so I'm re-sending to the list.)

On Wed, Jun 17, 2026, at 12:57, Theron York wrote:
> *1. "A C compositor would absolutely use wlroots" – that is not correct.*
> 

Yes, it is absolutely correct, for Xfce.  No Xfce developer is going to write a compositor from scratch without (something like) wlroots.  Again, Xfce is a small team of volunteers, and writing a compositor from scratch is a lot of work, work that none of us would be able to take on.

(More on libweston below.)

> *2. Auditability and dependency count*
> 
> You argued that Xfce is already large and not fully audited. That misses the point. The difference is *growth rate* and *churn*.
> 

I don't agree that there's a meaningful difference there.

> In contrast, libdrm, libinput, and Pixman are mature, stable, and have very few transitive dependencies.

And smithay depends on and makes use of all of those C libraries, through thin, safe, Rust wrappers.

> If we use Weston as a base, we inherit that stability without introducing a new, rapidly changing dependency graph.
> 

Well now you're contradicting yourself somewhat: Weston itself is a new dependency, and in your view that needs to be audited and vetted.  (But again: no one audits or vets these things!  You're worried about something being a larger burden in one path, when no one takes on that burden in _any_ path.)

On top of that, related to your first point: libweston is small and not very featureful; using it would still require a lot more work than using something like wlroots or smithay.  I didn't think of it as a serious alternative given our constraints.  Also consider that weston is a bit of an odd outlier (ironic considering it was the original reference implementation): it doesn't support a lot of useful extension protocols that clients rely on, that come more or less for free with wlroots or smithay.  This means even more work to add that support.

There's always a tension between "what do I write myself?" and "what do I depend on that someone else has written?"  It's the classic build vs. buy.  Using libweston would be much more of a "build" decision than using wlroots would be.  That means many more lines of code that the the Xfce team and I have to maintain.

If you're talking about forking weston itself, that seems even more difficult from this perspective.

> You said incremental builds are “tolerable.” That may be true for you, but a fresh build of a Rust project with all dependencies can take 10+ minutes on a typical laptop. That discourages casual contributors who just want to test a small patch. A C project using Weston or a minimal libdrm wrapper compiles in under two minutes. This matters for attracting new developers.

That's just your opinion.  I don't share it.

> *4. Distro packaging does not eliminate supply‑chain risk*

I never claimed it did.

> *5. “Lightweight” includes build‑time and dependencies*
> 
> You argued that Xfce’s philosophy applies only to runtime resources. I disagree. Xfce has always valued simplicity across the board – minimal dependencies, fast compilation, and low runtime overhead.
> 

That's again just your opinion.  I don't share it.  From our website:

"Xfce is a lightweight desktop environment for UNIX-like operating systems. It aims to be fast and low on system resources, while still being visually appealing and user friendly."

That's it.  That's the whole philosophy on being lightweight, which has nothing to do with dependencies or compilation.  That's something you've invented and made up on your own.

> I believe the trade‑offs of Rust+smithay are larger than necessary.
> 

Again, your opinion, which I don't share.

> I hope you will at least evaluate the alternatives before finalising the direction.

The direction was finalized in January, after evaluating the alternatives.  Nothing you've said changes the result of that evaluation.

Regards,
Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.xfce.org/pipermail/xfce4-dev/attachments/20260617/44d1b4bb/attachment-0001.htm>