wiki/FAQ: Mention reasons for not integrating Xwayland

1 files changed, 17 insertions, 0 deletions

diff --git a/wiki/FAQ.md b/wiki/FAQ.md
index aa046042..1d7b1de7 100644
--- a/wiki/FAQ.md
+++ b/wiki/FAQ.md
@@ -46,3 +46,20 @@ To run X11 apps, you can use [xwayland-satellite](https://github.com/Supreeeme/x
 Check [the Xwayland wiki page](./Xwayland.md) for instructions.
 
 Keep in mind that you can run many Electron apps such as VSCode natively on Wayland by passing the right flags, e.g. `code --ozone-platform-hint=auto`
+
+### Why doesn't niri integrate Xwayland like other compositors?
+
+A combination of factors:
+
+- Integrating Xwayland is quite a bit of work, as the compositor needs to implement parts of an X11 window manager.
+- You need to appease the X11 ideas of windowing, whereas for niri I want to have the best code for Wayland.
+- niri doesn't have a good global coordinate system required by X11.
+- You tend to get an endless stream of X11 bugs that take further time and effort away from other tasks.
+- There aren't actually that many X11-only clients nowadays, and xwayland-satellite takes perfect care of most of those.
+- niri isn't a Big Serious Desktop Environment which Must Support All Use Cases (and is Backed By Some Corporation).
+
+All in all, the situation works out in favor of avoiding Xwayland integration.
+
+Also, in the next release niri will have seamless built-in xwayland-satellite integration, that will solve the big rough edge of having to set it up manually.
+
+Besides, I wouldn't be too surprised if, down the road, xwayland-satellite becomes the standard way of integrating Xwayland into new compositors, since it takes on the bulk of the annoying work, and isolates the compositor from misbehaving clients.