3 ms·

While common X use evolved way from network (modern apps passing bitmaps around instead of primitives), the network architecture still have one huge advantage o

While common X use evolved way from network (modern apps passing bitmaps around instead of primitives), the network architecture still have one huge advantage over Wayland: it is a client server architecture, so one can restart things without losing state. That is, under X I can crash/restart the DE without losing any application state, open apps continue to run and simply connect to the new instance. But under Wayland any crash anywhere on the stack means all apps are killed and all work lost.

kaba0 5y ago
This is not mandated by the protocol — one is free to create a separate server and window manager program under wayland just as well. But I really don’t find it meaningful — such core functionality should just not crash (just as Xserver itself is not prone to crash, because than your work is also lost).
- AshamedCaptain 5y ago
  Not really; there is not a lot of support in the Wayland protocol for multiple clients sharing objects. See for example how difficult it is to emulate XEmbed, systray, wine, etc.
  - kaba0 5y ago
    How is that relevant? A client and the server is different processes already. Sharing it between 2 process or 3 is at that point meaningless. (Also, not everything has to be shared to a dumb window manager module)
    - AshamedCaptain 5y ago
      No, is not really meaningless. Basically, you assume from the server that each relevant object is owned and accessible by 1 client only. If 2 clients want to "own" the same object, they have to coordinate between themselves using an entirely different protocol so that only one client owns the object from the PoV of the compositor (you also can't do it through Wayland since it lacks generic IPC support, which X11 has even if poor). See https://www.winehq.org/pipermail/wine-devel/2021-December/203035.html https://www.winehq.org/pipermail/wine-devel/2021-December/20... If you want to make a separate window manager, it is likely that the result is going to be incompatible with most existing clients. But this seems par for the course for almost every Wayland extension so far (see Gnome...).
      - kaba0 5y ago
        Having more than one mutable reference to the same thing already begets advanced synchronization if that’s what you mean, but I don’t see how is that relevant. And beside gnome and kde there is a third big group of wayland compositors based on wlroots which does support some form of common set of extensions not in core, effectively making you write only the wm part.
        AshamedCaptain 5y ago
        > but I don’t see how is that relevant. Because this prevents creation of a separate window manager program. You can do all of this with the core protocol in X11. You can't do any of it in Wayland almost by design. The entire idea of a client getting simultaneous access to the objects of another client is not in the protocol. You cannot render in another process surface. You cannot even iterate over its windows! The role of the compositor is hardcoded in the protocol design. The closest thing you can do is to write some type of modular compositor which speaks _yet another_ protocol with the window manager module (or even exists within the same process). But this is not like in X11, where you plug new things (e.g. a new WM, a new pager) without having to restart the X server, much less having to change it.

kaba0 5y ago

This is not mandated by the protocol — one is free to create a separate server and window manager program under wayland just as well. But I really don’t find it meaningful — such core functionality should just not crash (just as Xserver itself is not prone to crash, because than your work is also lost).

AshamedCaptain 5y ago
Not really; there is not a lot of support in the Wayland protocol for multiple clients sharing objects. See for example how difficult it is to emulate XEmbed, systray, wine, etc.
- kaba0 5y ago
  How is that relevant? A client and the server is different processes already. Sharing it between 2 process or 3 is at that point meaningless. (Also, not everything has to be shared to a dumb window manager module)
  - AshamedCaptain 5y ago
    No, is not really meaningless. Basically, you assume from the server that each relevant object is owned and accessible by 1 client only. If 2 clients want to "own" the same object, they have to coordinate between themselves using an entirely different protocol so that only one client owns the object from the PoV of the compositor (you also can't do it through Wayland since it lacks generic IPC support, which X11 has even if poor). See https://www.winehq.org/pipermail/wine-devel/2021-December/203035.html https://www.winehq.org/pipermail/wine-devel/2021-December/20... If you want to make a separate window manager, it is likely that the result is going to be incompatible with most existing clients. But this seems par for the course for almost every Wayland extension so far (see Gnome...).
    - kaba0 5y ago
      Having more than one mutable reference to the same thing already begets advanced synchronization if that’s what you mean, but I don’t see how is that relevant. And beside gnome and kde there is a third big group of wayland compositors based on wlroots which does support some form of common set of extensions not in core, effectively making you write only the wm part.
      - AshamedCaptain 5y ago
        > but I don’t see how is that relevant. Because this prevents creation of a separate window manager program. You can do all of this with the core protocol in X11. You can't do any of it in Wayland almost by design. The entire idea of a client getting simultaneous access to the objects of another client is not in the protocol. You cannot render in another process surface. You cannot even iterate over its windows! The role of the compositor is hardcoded in the protocol design. The closest thing you can do is to write some type of modular compositor which speaks _yet another_ protocol with the window manager module (or even exists within the same process). But this is not like in X11, where you plug new things (e.g. a new WM, a new pager) without having to restart the X server, much less having to change it.