4 ms·

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, s

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.

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.