diff options
| -rw-r--r-- | wiki/FAQ.md | 17 |
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. |