mirror of
https://github.com/niri-wm/niri.git
synced 2026-06-21 02:01:55 +07:00
wiki/FAQ: Mention reasons for not integrating Xwayland
This commit is contained in:
+17
@@ -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.
|
||||
|
||||
Reference in New Issue
Block a user