3 ms·

I'm not sure what are the changes in the X11 server implementation you're talking about, but if they do indeed meet every single possible use case, then maybe s

I'm not sure what are the changes in the X11 server implementation you're talking about, but if they do indeed meet every single possible use case, then maybe someone can bring them over to Wayland? I'm sorry to say, but you have to acknowledge these are novelty applications and are really not driving progress right now, the main focus is in getting all the other applications to work. FYI there is some prior art for poking a security hole in the Wayland server to support X11 features, but obviously not all implementations will want to support this: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/master/unstable/xwayland-keyboard-grab/xwayland-keyboard-grab-unstable-v1.xml https://gitlab.freedesktop.org/wayland/wayland-protocols/-/b...

bitwize 6y ago
The X11 server changes would involve isolating clients by default, keeping them unaware of windows they did not create themselves... but allowing a whitelist of trusted clients that can see everything. This is inimical to the design principles of Wayland, whose security policy is to isolate all clients -- no exceptions, no escape. The 1984 Mac was largely a novelty, but it was one that demonstrated possibilities. There are non-novelty applications that are precluded by Wayland. Something like EXWM could not be done. You cannot write a standalone virtual-desktop switcher, it must be integrated into the compositor. Et weary cetera. Wayland is very opinionated about the kinds of programs you can write for it, and if you want to go beyond that you must traverse the step function into "write your own compositor".
- cycloptic 6y ago
  See the protocol extension I linked, there are absolutely exceptions and escapes that can fall back on the X11 way of doing things, and could even work with such X11 client isolation, but somebody would have to take the time to actually design and implement them and figure out how to get them to work with the security model used by the Wayland implementations. That is really the problem, it's only an implementation detail if you choose to do it by hacking the X server or you choose to make a new D-Bus API for it, or whatever. (i.e. there is no real reason XWayland needs extra extensions, it could call a D-Bus API if necessary, and that may even be desirable because the D-Bus API would be forward-compatible with newer Wayland applications)

bitwize 6y ago

The X11 server changes would involve isolating clients by default, keeping them unaware of windows they did not create themselves... but allowing a whitelist of trusted clients that can see everything. This is inimical to the design principles of Wayland, whose security policy is to isolate all clients -- no exceptions, no escape. The 1984 Mac was largely a novelty, but it was one that demonstrated possibilities. There are non-novelty applications that are precluded by Wayland. Something like EXWM could not be done. You cannot write a standalone virtual-desktop switcher, it must be integrated into the compositor. Et weary cetera. Wayland is very opinionated about the kinds of programs you can write for it, and if you want to go beyond that you must traverse the step function into "write your own compositor".

cycloptic 6y ago
See the protocol extension I linked, there are absolutely exceptions and escapes that can fall back on the X11 way of doing things, and could even work with such X11 client isolation, but somebody would have to take the time to actually design and implement them and figure out how to get them to work with the security model used by the Wayland implementations. That is really the problem, it's only an implementation detail if you choose to do it by hacking the X server or you choose to make a new D-Bus API for it, or whatever. (i.e. there is no real reason XWayland needs extra extensions, it could call a D-Bus API if necessary, and that may even be desirable because the D-Bus API would be forward-compatible with newer Wayland applications)