<!DOCTYPE html><html><head><title></title><style type="text/css">p.MsoNormal,p.MsoNoSpacing{margin:0}</style></head><body><div>Nice! I was really worried about the complexity of the embedded compositor stuff, even if it's supposedly the "right" way to do it. Making something that preserves the semantics of the plug/socket approach seems like a very natural fit, and should make it much easier to support both X11 and Wayland without the panel -- or especially plugin authors -- needing to do a lot of extra work.<br></div><div><br></div><div> -b<br></div><div><br></div><div>On Fri, Oct 28, 2022, at 04:13, Gaël Bonithon wrote:<br></div><blockquote type="cite" id="qt" style=""><div style="font-family:Arial;font-size:14px;"><div><span>Hi all,</span><br></div><div><br></div><div><span>It seems that I have found a viable, albeit non-native, solution for external panel plugins on Wayland (i.e. plugins running in a separate process).</span><br></div><div><br></div><div><span>Since I really didn't want to go down the embedding compositor route, I followed a bit of the same idea as the XDG foreign protocol, but for layer shell windows, and using D-Bus instead of the compositor to synchronize the "socket" and "plug" geometries, to follow the GTK terminology.</span><br></div><div><br></div><div><span>It works quite well, better than I would have thought in fact, especially when moving the panel: since the overlay of the plug and socket is not managed internally by the compositor, we can see that the plugins dissociate a little from the panel when moving, but it remains reasonable. It is not excluded that other side effects appear here or there though, knowing that it also depends on the way the compositor implements the layer-shell protocol.</span><br></div><div><br></div><div><span>On the other hand, some graphical limitations related to the XEmbed protocol do not apply anymore, as for background images in this issue [1]. By making the plug background transparent, we obtain a homogeneous rendering on the whole panel as with internal plugins.</span><br></div><div><br></div><div><span>Concerning the code structure it's quite natural, since it keeps the socket/plug structure, and it reuses all the process management and IPC mechanism already in place. I just added some D-Bus signals/methods, and an abstraction layer to distinguish X11 and Wayland implementations of socket/plug.</span><br></div><div><br></div><div><span>This way, if by chance an extension of the XDG foreign protocol to layer shell windows should come along, or anything else that keeps this socket/plug structure, maintenance should be quite simple. I have little hope that this will happen though, reading this rather informative issue [2] ("Allow embedding foreign wl_surfaces", already quoted in previous threads, and not only closed, but locked...).</span><br></div><div><br></div><div><span>With this I'm getting closer to something that can be merged anyway [3], it should be good soon after the release of Xfce 4.18 I think :)</span><br></div></div><div style="font-family:Arial;font-size:14px;"><br></div><div class="qt-protonmail_signature_block" style="font-family:Arial;font-size:14px;"><div class="qt-protonmail_signature_block-user"><div>Cheers,<br></div><div>Gaël<br></div><div><br></div></div><div style="font-family:Arial;font-size:14px;">--<br></div><div style="font-family:Arial;font-size:14px;"><div><span>[1] <a target="_blank" rel="noreferrer nofollow noopener" href="https://gitlab.xfce.org/xfce/xfce4-panel/-/issues/107">https://gitlab.xfce.org/xfce/xfce4-panel/-/issues/107</a></span><br></div><div><span>[2] <a target="_blank" rel="noreferrer nofollow noopener" href="https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/74">https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/74</a></span><br></div><div><span>[3] <a target="_blank" rel="noreferrer nofollow noopener" href="https://gitlab.xfce.org/xfce/xfce4-panel/-/merge_requests/103">https://gitlab.xfce.org/xfce/xfce4-panel/-/merge_requests/103</a></span><br></div></div></div><div>_______________________________________________<br></div><div>Xfce4-dev mailing list<br></div><div><a href="mailto:Xfce4-dev@xfce.org">Xfce4-dev@xfce.org</a><br></div><div><a href="https://mail.xfce.org/mailman/listinfo/xfce4-dev">https://mail.xfce.org/mailman/listinfo/xfce4-dev</a><br></div></blockquote><div><br></div></body></html>