> On 25 May 2019, at 14:44, Simon Ser <cont...@emersion.fr> wrote: > > Hi, > >> On Saturday, May 25, 2019 4:23 PM, Alexandre Mazari <sca...@gmail.com> wrote: >> Greetings wayland-devel, >> >> I am currently looking at ways to abstract Xisms in Plasma >> global-menu daemon and applet and provide a Wayland implementation. >> >> X11/xcb is currently used there to set and obtain to/from the >> *active* window some metadata (atoms) relative to the DBus address of >> the application menu provider. >> >> A wayland implementation [0] should first be able to track the active >> window. >> AFAIK, none of the current protocols provides such mechanism. >> I wonder whether that is by design to avoid some info leakage or >> would an activeSurface/activeWindow method/signal couple make sense >> in xdg-shell or xdg_surface? > > Yes, this is by design. Regular clients don't have any way to list > other clients' toplevels or to manage them, unlike on X11. > > I don't think it would make sense to add such a request/event to > xdg-shell, because this is out-of-scope for xdg-shell. > >> Moreover, the shell compositor often has the best knowledge of the >> link between surface/window and their owner application. Specific >> clients (like the global-menu) might be interested in this data, >> avoiding convoluted ways to do the matching. a get_app_id request in >> xdg shell could prove useful there. >> >> What do you think? > > Some projects like GNOME make the compositor responsible for drawing > desktop UI elements like a global menu. This has the upside of being > easy to implement, but has also some downsides: for instance the > compositor is responsible for drawing complex UI elements, which slows > down composition and makes it more likely to crash. > > If you cannot or don't want to do it this way, other compositors > (e.g. Weston, KDE as far as I've understood, and many wlroots > compositors) typically use a dedicated protocol for privileged clients. > In the case of KWin, the existing KDE-specific Wayland protocols are > here: > https://github.com/KDE/kwayland/tree/master/src/client/protocols > > It's worth noting that as of now, only Weston restricts access to > privileged protocols to a limited set of clients. In other compositors, > these protocols are exposed to all clients (and this has security > implications). > > Regarding this specific use-case, wlroots has standardized a protocol > for listing and managing toplevels: > https://github.com/swaywm/wlr-protocols/blob/master/unstable/wlr-foreign-toplevel-management-unstable-v1.xml >
Are there any examples of server-side implementations of plasma-window-management.xml on libweston? Alternatively, are there any plain C implementations of the same without all the KDE/Qt stuff? What would a basic boilerplate implementation of plasma-window-management look like on libweston? Regards adlo _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel