On Monday, May 27, 2019 10:27 AM, adlo <[email protected]> wrote: > > On 25 May 2019, at 14:44, Simon Ser [email protected] wrote: > > > Hi, > > > > > On Saturday, May 25, 2019 4:23 PM, Alexandre Mazari [email protected] > > > 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?
No, plasma-window-management is a private KDE protocol. If you want a protocol that has been designed to be cross-compositor, I'd suggest looking into wlr-foreign-toplevel-management (a plain C implementation exists in wlroots, it should be pretty self-contained). _______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
