Deciding the Linux strategy

[xStrom]

Druid never settled on a clear Linux strategy. At first there was only the GTK backend due to the simplicity of implementation.
Then there were experimental backends for X11 and Wayland. Bringing the total to three. No clear focus, lots of effort spread thin.
There were several attempts to reach some sort of clarity on how to reduce the scope, but unfortunately no decisions made.

Complexity kills. Lack of focus kills. The scope of Glazier is already enormous with targeting Windows, macOS, web (sort of), and tentative plans for both Android and iOS. Having multiple backends for Linux doesn't seem like well spent resources. Yes there are occasional champions who contribute to specific backends, but for the general success of Glazier new features should work well on all platforms and receive proper maintenance. Far fewer volunteer for such ongoing work. Also, speaking as someone who tests all the Glazier platforms, I would love to spend less time on all the various Linux quirks.

I think it would serve us well to reduce scope and increase focus.

With that in mind, I went through the historic Druid discussion threads and also did a bit of digging across the Linux ecosystem landscape to see how things are today and how things are likely to be in a few years.

Cutting options

The first question is whether we should drop GTK or embrace it.

If we embrace GTK, then it would be rather straightforward to drop support for both X11 and Wayland native backends.

However if we drop GTK then we're still left with both X11 and Wayland. Still double the number of backends per platform compared to other platforms. Thus I think in the case where we drop GTK we should also seriously consider dropping X11 and focus solely on Wayland.

With such a decision tree in mind, I'll present various points regarding each of the backends.

GTK

Benefits of keeping

• GTK has already solved a lot of issues that we'll need to redo.

  • Think menus, window decorations, alerts and other utility dialogs.
  • .. although rewriting those does align with the Rewrite-it-in-Rust ethos.

• We've already implemented a lot of the GTK integration.

  • Unclear how much of it has to be rewritten for GTK 4 though.

• Probably the fastest path, in dev time, to a stable Linux backend.

• Most attractive when the alternative is to keep both Wayland and X11 as opposed to only Wayland.
  As GTK 4 will provide both X11 and Wayland support for us, while being only a single backend for Glazier.

Benefits of removing

• There is some uncertainty around how well the Glazier model with Vello can even work with GTK.
  There are various claims that it can be done, but at the moment nobody has actually spent the time to do it.

• People have complained about the GTK compile times for years. Most recently in #101.
  Some historic Druid tests showed it almost an order of magnitude slower than Windows.

• People have also complained about app startup time.

• Significantly reduces our dependency graph. A lot of it written in C. Results in faster compile times and potentially fewer security bugs.

• Gives us a higher degree of control.

  • Ability to hunt for more performance.
  • Ability to use/create more niche features.
  • Ability to target a wider range of uses like VST plugins.

• We're still on GTK 3 and should probably migrate to GTK 4. Removing the GTK backend skips that work.

• Support for running on systems that don't have GTK installed. Admittedly not too many of those, but the dependency is huge.

Wayland

• Clearly the future. Various major Linux ecosystem projects are overwhelmingly in agreement.
  The differences in thought come from the assessment of progress towards it.
  However the progress is towards it.

• We already need to do a large amount of work on our Wayland backend.
  It would be a lot easier to justify this focus if this was essentially synonymous with Linux support.

• Removal only makes sense if we focus on GTK instead.

X11

Benefits of keeping

• We've already done a good chunk of the work.

• Ability to run on setups that are either running old distributions or are custom configured to run X11.

• There isn't a lot of statistics available on display server usage, but we have a tiny bit - sample size 5500 across distributions.
  Keep in mind that the kind of person that would seek out self reporting like this is also more likely to change their defaults.
  So reality is probably skewed more towards distribution defaults. That said, I'll link three Wayland usage charts.

  • Ubuntu Jan 2022 23.5% > Jan 2023 55.6%
  • Fedora Jan 2022 60.7% > Jan 2023 70.6%
  • All Jan 2022 15.1% > Jan 2023 27.0%

  The trend is aggressively towards Wayland. Wayland has been available for a long time, but adoption has really accelerated in just the last few years. All signs point towards the acceleration only growing. However it is an open question how long the last 10% will hold out.

Benefits of removing

• X11 is increasingly abandoned.
  It still works but is missing support for modern features and that list will only grow.
  Legacy quirks are guaranteed to remain.

• Significantly reduces our maintenance burden of the Linux platform.

• Reduces our dependency graph even more.

• App developer experience improves drastically if Linux is just one backend,
  because otherwise the app code needs to perform runtime checks on X11 vs Wayland guarded by a Linux cfg attribute.

• X11 has no support for wide color gamuts or HDR and there are no plans either.
  Wayland doesn't have real support either, but there is serious ongoing work.
  For us to support these modern features X11 would at a minimum be a heavily degraded experience.

• GTK team considered removing the X11 backend from GTK for the future GTK 5 release.
  Their current plan is to stop building the X11 backend by default in GTK 5,
  but they also aren't rushing to delete the code .. at least until the next major refactor.
  In general, the vibe I get from the GTK team is that they don't want to spend any more resources on X11 support.

• Qt 6 docs state:
  In fact, it is difficult to run a client fluidly with X11, and reach 60 fps without tearing.
  Wayland, in contrast, is easier to implement, has better performance,
  and contains all the necessary parts to run efficiently on modern graphics hardware.
  Running fluidly at 60 fps, or indeed 144 fps, is one of the core goals of the Linebender stack.

• If both GTK and Qt, the two biggest Linux GUI toolkits, are convinced that Wayland is the superior future,
  then why would we, with less resources, invest in X11 support for our toolkit that won't even be ready for years.

• Opportunity for Glazier to help shape the future of Linux desktop.
  Yes Wayland has issues. If the path of least resistance is to just go back to X11, then Wayland issues remain.
  If switching back to X11 isn't easy, then the path of least resistance becomes to fix the Wayland issues.
  Instead of helping keep the fragmentation the way it is, we could be championing for the shift.

• In the bigger Linebender picture we're already building for the future by targeting compute shaders and WebGPU.
  It seems to fit thematically that we'll also focus on the latest display server.
  Although I guess you could make the case that supporting X11 is similar to having a CPU fallback in Vello.

• GNOME has defaulted to Wayland since ca Fedora 25.

• The KDE team is pushing for Wayland by default in the upcoming Plasma 6 release.
  (Estimated release date Q1 2024)

• Fedora has defaulted to Wayland with Plasma since Fedora 34, and with GNOME since Fedora 25.

• The Fedora team is pushing to take it even further and have the Fedora Plasma 6 ship without X11.

• Red Hat Enterprise Linux 9 deprecated X11, defaults to Wayland. X11 planned for removal in RHEL 10.

• Ubuntu has defaulted to Wayland since Ubuntu 21.04.

• Debian has defaulted to Wayland with GNOME since Debian 10.

• Glazier 1.0 isn't likely for another few years.
  While large Linux distributions are looking to remove as much X11 code as they can,
  should we be looking to write new X11 code for 2025 and beyond? Seems like swimming against the current.

• It is better to cut scope and increase focus.
  Deliver a single Wayland backend that is excellent, instead of two backends that are merely good.

Previous discussions

• The goal and scope of the GTK backend in druid-shell
• What are the goals and tradeoffs for the linux backend?
• The ideal Wayland backend
• #druid > Wayland
• #druid > The long term strategy on linux

Feedback welcome

Given that the primary issue with having three Linux backends is the amount of work required, I especially want to encourage people to respond here if they have even tentative plans to contribute work towards specific backends.

In general, if anyone has more reasons to add or want to amplify one of the above reasons on why we should go with any of these options, please share your thoughts.

[jaredoconnell]

Some other relevant points:

• It appears that you can run wayland under X11 for those that need to run X11 still. If the compatibility is good, then it reduces the importance of maintaining our support for future abandonware. https://unix.stackexchange.com/questions/482129/can-i-run-wayland-application-in-x
• The GTK backend likely causes licensing issues. It's licensed under the GNU Lesser General Public License. That adds a large burden to all non-GPN and non-LGPL projects. And it's not obvious to the developers that use our projects due to us using more permissive licenses. It basically means they need to treat using our project as LGPL on linux, and apache-2.0 everywhere else.
• As someone who recently started experimenting with X11 and Wayland, the barrier to entry is especially high for X11.

I think it would be a good idea for those here that are still using X11 to test out running wayland under X11 (as described by the link above) to see if that is enough of a workaround to support legacy systems.

[xStrom]

There has been a bit of additional discussion on this topic in #glazier > Deciding the Linux strategy.

We also had office hours today (2023-06-22) and spent most of the time discussing this issue.
We reached an agreement on the general strategy. 🎉

• Wayland is indeed the future and our Wayland backend will become the primary focus of our Linux strategy.
• Because our X11 backend is currently our most functional Linux backend we will not immediately remove it.
  • We will migrate from the current compile time backend selection to a runtime selection between Wayland and X11.
• We are introducing backend tiering. This is a policy of support.
  • Tier 1 backends will receive our focus. The Wayland backend will become tier 1 alongside Windows and macOS.
  • Tier 2 backends are only guaranteed to compile and are more likely to have bugs or lack features. These backends are also likely to be removed at some point in the future if they would otherwise hold back progress of tier 1 backends - unless there is a champion who eliminates the problem.
  • X11 will become a tier 2 backend alongside web. One example of a future feature that threatens removal is proper Linux IME support.
• We don't have a champion to fix the raw window handle issue with GTK so we're just going to remove the GTK backend.
• For features that worked with GTK but aren't easily replicated with Wayland:
  • Window decorations - we will start by focusing on making these just work in some form by using e.g. sctk-adwaita but in the long term will need a better solution that doesn't introduce a whole second text stack.
  • Menus - support will be polyfilled at a higher level (e.g. Xilem) but we may add some sort of assistive API to Glazier.

[dvc94ch]

Why not let xilem polyfill window decorations too? There is a Wayland extension for server side window decorations and if you're using a tiling window manager you don't want decorations anyway

[xStrom]

That is a very good question and it may make sense to do that. It would certainly solve the double text stack issue. Right now I personally haven't gotten too deep into Wayland window deocrations yet so I would say it's an open research question.

[dhardy]

Regarding decorations, the only thing I would want in Glazier is the ability to detect whether platform-provided decorations are supported (e.g. KDE on Wayland does, I think Gnome doesn't), and to control whether these are used (e.g. some apps prefer to use themed decorations).

I don't see much value in adding decoration support in Glazier (like winit does). Especially if Glazier is targeted only at UI toolkits.

Menus

One thing about client-side decorations is that the client needs to be able to open the platform's window context menu. Well, the client should be able to, though some themed apps don't appear to support this.

[flukejones]

However if we drop GTK then we're still left with both X11 and Wayland.

There is very little reason to keep X11 around. The general consensus in the Linux community seems to be growing very steadily towards a Wayland-only future - https://linux.slashdot.org/story/23/07/17/0159246/is-wayland-becoming-the-favored-way-to-get-a-gui-on-linux

My apologies for a drive-by 2-cents comment, but a project I highly depend on (lapce) is dependant on glazier, and I would love to see a narrower focus agreed on for glazier.

Edit: I will additionally add that dropping GTK as a backend seems to be a logical and good choice. It will reduce the workload, and from what I've seen around the places I lurk the primary reason many are choosing glazier is not for a GTK backend, but for windowing only (and the additional features expected of a desktop window). I'll reiterate that focusing solely on a single backend is “Right Thing™:”

[jaredoconnell]

However if we drop GTK then we're still left with both X11 and Wayland.

There is very little reason to keep X11 around. The general consensus in the Linux community seems to be growing very steadily towards a Wayland-only future - https://linux.slashdot.org/story/23/07/17/0159246/is-wayland-becoming-the-favored-way-to-get-a-gui-on-linux

My apologies for a drive-by 2-cents comment, but a project I highly depend on (lapce) is dependant on glazier, and I would love to see a narrower focus agreed on for glazier.

Edit: I will additionally add that dropping GTK as a backend seems to be a logical and good choice. It will reduce the workload, and from what I've seen around the places I lurk the primary reason many are choosing glazier is not for a GTK backend, but for windowing only (and the additional features expected of a desktop window). I'll reiterate that focusing solely on a single backend is “Right Thing™:”

According to the discussions in the office hours meeting, we dropped GTK, and set X11 as a tier 2 backend, meaning that it will not be as much of a priority, and would be removed if it becomes too much of a limiting factor.

In addition, there is progress towards re-writing the wayland backend: #107

[nyabinary]

I assume Wayland is tier 1, correct?

[xStrom]

I assume Wayland is tier 1, correct?

That is correct.