<!DOCTYPE html><html><head><title></title></head><body><div>Hi Theron,</div><div><br></div><div>(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.)</div><div><br></div><div>On Wed, Jun 17, 2026, at 12:57, Theron York wrote:</div><blockquote type="cite" id="qt" style=""><p class="qt-ds-markdown-paragraph"><b><span class="qt-">1. "A C
          compositor would absolutely use wlroots" – that is not
          correct.</span></b></p></blockquote><div><br></div><div>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.</div><div><br></div><div>(More on libweston below.)</div><div><br></div><blockquote type="cite" id="qt" style=""><p class="qt-ds-markdown-paragraph"><b><span class="qt-">2.
          Auditability and dependency count</span></b></p><p class="qt-ds-markdown-paragraph"><span class="qt-">You argued that Xfce
        is already large and not fully audited. That misses the point.
        The difference is </span><i><span class="qt-">growth rate</span></i><span class="qt-"> and </span><i><span class="qt-">churn</span></i><span class="qt-">.</span></p></blockquote><div><br></div><div>I don't agree that there's a meaningful difference there.</div><div><br></div><blockquote type="cite"><div>In contrast, libdrm, libinput, and Pixman are mature, stable, and have very few transitive dependencies.</div></blockquote><div><br></div><div>And smithay depends on and makes use of all of those C libraries, through thin, safe, Rust wrappers.</div><div><br></div><blockquote type="cite" id="qt" style=""><p class="qt-ds-markdown-paragraph"><span class="qt-">If we use Weston as
        a base, we inherit that stability without introducing a new,
        rapidly changing dependency graph.</span></p></blockquote><div><br></div><div>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.)</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>If you're talking about forking weston itself, that seems even more difficult from this perspective.</div><div><br></div><blockquote type="cite" id="qt" style=""><div><hr><span class="qt-">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.</span></div></blockquote><div><br></div><div>That's just your opinion.  I don't share it.</div><div><br></div><blockquote type="cite" id="qt" style=""><div><hr><b><span class="qt-">4. Distro
          packaging does not eliminate supply‑chain risk</span></b></div></blockquote><div><br></div><div>I never claimed it did.</div><div><br></div><blockquote type="cite" id="qt" style=""><p class="qt-ds-markdown-paragraph"><b><span class="qt-">5.
          “Lightweight” includes build‑time and dependencies</span></b></p><p class="qt-ds-markdown-paragraph"><span class="qt-">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.</span></p></blockquote><div><br></div><div>That's again just your opinion.  I don't share it.  From our website:</div><div><br></div><div>"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."</div><div><br></div><div>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.</div><div><br></div><blockquote type="cite" id="qt" style=""><p class="qt-ds-markdown-paragraph"><span class="qt-">I believe the trade‑offs of
        Rust+smithay are larger than necessary.</span></p></blockquote><div><div><br></div><div>Again, your opinion, which I don't share.</div></div><div><br></div><blockquote type="cite" id="qt" style=""><div><span class="qt-">I hope you will at least
        evaluate the alternatives before finalising the direction.</span></div></blockquote><div><br></div><div>The direction was finalized in January, after evaluating the alternatives.  Nothing you've said changes the result of that evaluation.</div><div><br></div><div>Regards,</div><div>Brian</div></body></html>