Re: Concerns Regarding the Choice of Rust for the Xfce Wayland Compositor

"Brian Tarricone" <[email protected]> Wed, 17 Jun 2026 14:14:53 -0700
Newsgroups gmane.comp.desktop.xfce.devel.version4
Message-ID <[email protected]>
--===============8291144002620248255==
Content-Type: multipart/alternative;
 boundary=26b6407138549de73f6c3d426f383e531735c641

--26b6407138549de73f6c3d426f383e531735c641
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi Theron,

(Seems you dropped xfce4-dev from the mailing list.  Didn't notice befor=
e 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" =E2=80=93 that is no=
t correct.*
>=20

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 scra=
tch 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*
>=20
> You argued that Xfce is already large and not fully audited. That miss=
es the point. The difference is *growth rate* and *churn*.
>=20

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, throug=
h thin, safe, Rust wrappers.

> If we use Weston as a base, we inherit that stability without introduc=
ing a new, rapidly changing dependency graph.
>=20

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 somethi=
ng being a larger burden in one path, when no one takes on that burden i=
n _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 a=
lternative given our constraints.  Also consider that weston is a bit of=
 an odd outlier (ironic considering it was the original reference implem=
entation): it doesn't support a lot of useful extension protocols that c=
lients 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 usin=
g wlroots would be.  That means many more lines of code that the the Xfc=
e team and I have to maintain.

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

> You said incremental builds are =E2=80=9Ctolerable.=E2=80=9D That may =
be true for you, but a fresh build of a Rust project with all dependenci=
es can take 10+ minutes on a typical laptop. That discourages casual con=
tributors 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=E2=80=91chain risk*

I never claimed it did.

> *5. =E2=80=9CLightweight=E2=80=9D includes build=E2=80=91time and depe=
ndencies*
>=20
> You argued that Xfce=E2=80=99s philosophy applies only to runtime reso=
urces. I disagree. Xfce has always valued simplicity across the board =E2=
=80=93 minimal dependencies, fast compilation, and low runtime overhead.
>=20

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

"Xfce is a lightweight desktop environment for UNIX-like operating syste=
ms. It aims to be fast and low on system resources, while still being vi=
sually 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=E2=80=91offs of Rust+smithay are larger than neces=
sary.
>=20

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

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

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

Regards,
Brian
--26b6407138549de73f6c3d426f383e531735c641
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title></head><body><div>Hi Theron,</=
div><div><br></div><div>(Seems you dropped xfce4-dev from the mailing li=
st.&nbsp; Didn't notice before sending you my reply, so I'm re-sending t=
o the list.)</div><div><br></div><div>On Wed, Jun 17, 2026, at 12:57, Th=
eron York wrote:</div><blockquote type=3D"cite" id=3D"qt" style=3D""><p =
class=3D"qt-ds-markdown-paragraph"><b><span class=3D"qt-">1. "A C=0A    =
      compositor would absolutely use wlroots" =E2=80=93 that is not=0A =
         correct.</span></b></p></blockquote><div><br></div><div>Yes, it=
 is absolutely correct, for Xfce.&nbsp; No Xfce developer is going to wr=
ite a compositor from scratch without (something like) wlroots.&nbsp; Ag=
ain, Xfce is a small team of volunteers, and writing a compositor from s=
cratch is a lot of work, work that none of us would be able to take on.<=
/div><div><br></div><div>(More on libweston below.)</div><div><br></div>=
<blockquote type=3D"cite" id=3D"qt" style=3D""><p class=3D"qt-ds-markdow=
n-paragraph"><b><span class=3D"qt-">2.=0A          Auditability and depe=
ndency count</span></b></p><p class=3D"qt-ds-markdown-paragraph"><span c=
lass=3D"qt-">You argued that Xfce=0A        is already large and not ful=
ly audited. That misses the point.=0A        The difference is </span><i=
><span class=3D"qt-">growth rate</span></i><span class=3D"qt-"> and </sp=
an><i><span class=3D"qt-">churn</span></i><span class=3D"qt-">.</span></=
p></blockquote><div><br></div><div>I don't agree that there's a meaningf=
ul difference there.</div><div><br></div><blockquote type=3D"cite"><div>=
In contrast, libdrm, libinput, and Pixman are mature, stable, and have v=
ery few transitive dependencies.</div></blockquote><div><br></div><div>A=
nd smithay depends on and makes use of all of those C libraries, through=
 thin, safe, Rust wrappers.</div><div><br></div><blockquote type=3D"cite=
" id=3D"qt" style=3D""><p class=3D"qt-ds-markdown-paragraph"><span class=
=3D"qt-">If we use Weston as=0A        a base, we inherit that stability=
 without introducing a new,=0A        rapidly changing dependency graph.=
</span></p></blockquote><div><br></div><div>Well now you're contradictin=
g yourself somewhat: Weston itself is a new dependency, and in your view=
 that needs to be audited and vetted.&nbsp; (But again: no one audits or=
 vets these things!&nbsp; You're worried about something being a larger =
burden in one path, when no one takes on that burden in _any_ path.)</di=
v><div><br></div><div>On top of that, related to your first point:&nbsp;=
libweston is small and not very featureful; using it would still require=
 a lot more work than using something like wlroots or smithay.&nbsp; I d=
idn't think of it as a serious alternative given our constraints.&nbsp; =
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 l=
ess for free with wlroots or smithay.&nbsp; This means even more work to=
 add that support.</div><div><br></div><div>There's always a tension bet=
ween "what do I write myself?" and "what do I depend on that someone els=
e has written?"&nbsp; It's the classic build vs. buy.&nbsp; Using libwes=
ton would be much more of a "build" decision than using wlroots would be=
.&nbsp; That means many more lines of code that the the Xfce team and I =
have to maintain.</div><div><br></div><div>If you're talking about forki=
ng weston itself, that seems even more difficult from this perspective.<=
/div><div><br></div><blockquote type=3D"cite" id=3D"qt" style=3D""><div>=
<hr><span class=3D"qt-">You said incremental=0A        builds are =E2=80=
=9Ctolerable.=E2=80=9D That may be true for you, but a fresh=0A        b=
uild of a Rust project with all dependencies can take 10+=0A        minu=
tes on a typical laptop. That discourages casual=0A        contributors =
who just want to test a small patch. A C project=0A        using Weston =
or a minimal libdrm wrapper compiles in under two=0A        minutes. Thi=
s matters for attracting new developers.</span></div></blockquote><div><=
br></div><div>That's just your opinion.&nbsp; I don't share it.</div><di=
v><br></div><blockquote type=3D"cite" id=3D"qt" style=3D""><div><hr><b><=
span class=3D"qt-">4. Distro=0A          packaging does not eliminate su=
pply=E2=80=91chain risk</span></b></div></blockquote><div><br></div><div=
>I never claimed it did.</div><div><br></div><blockquote type=3D"cite" i=
d=3D"qt" style=3D""><p class=3D"qt-ds-markdown-paragraph"><b><span class=
=3D"qt-">5.=0A          =E2=80=9CLightweight=E2=80=9D includes build=E2=80=
=91time and dependencies</span></b></p><p class=3D"qt-ds-markdown-paragr=
aph"><span class=3D"qt-">You argued that=0A        Xfce=E2=80=99s philos=
ophy applies only to runtime resources. I disagree.=0A        Xfce has a=
lways valued simplicity across the board =E2=80=93 minimal=0A        dep=
endencies, fast compilation, and low runtime overhead.</span></p></block=
quote><div><br></div><div>That's again just your opinion.&nbsp; I don't =
share it.&nbsp; From our website:</div><div><br></div><div>"Xfce is a li=
ghtweight desktop environment for UNIX-like operating=20=0Asystems. It a=
ims to be fast and low on system resources, while still=20=0Abeing visua=
lly appealing and user friendly."</div><div><br></div><div>That's it.&nb=
sp; That's the whole philosophy on being lightweight, which has nothing =
to do with dependencies or compilation.&nbsp; That's something you've in=
vented and made up on your own.</div><div><br></div><blockquote type=3D"=
cite" id=3D"qt" style=3D""><p class=3D"qt-ds-markdown-paragraph"><span c=
lass=3D"qt-">I believe the trade=E2=80=91offs of=0A        Rust+smithay =
are larger than necessary.</span></p></blockquote><div><div><br></div><d=
iv>Again, your opinion, which I don't share.</div></div><div><br></div><=
blockquote type=3D"cite" id=3D"qt" style=3D""><div><span class=3D"qt-">I=
 hope you will at least=0A        evaluate the alternatives before final=
ising the direction.</span></div></blockquote><div><br></div><div>The di=
rection was finalized in January, after evaluating the alternatives.&nbs=
p; Nothing you've said changes the result of that evaluation.</div><div>=
<br></div><div>Regards,</div><div>Brian</div></body></html>
--26b6407138549de73f6c3d426f383e531735c641--

--===============8291144002620248255==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xfce4-dev mailing list
[email protected]
https://mail.xfce.org/mailman/listinfo/xfce4-dev

--===============8291144002620248255==--