(No Subject)

[Simon Ser]

On Monday, May 27, 2019 10:27 AM, adlo <adloconwy at gmail.com> wrote:
> > On 25 May 2019, at 14:44, Simon Ser contact at emersion.fr wrote:
>
> > Hi,
> >
> > > On Saturday, May 25, 2019 4:23 PM, Alexandre Mazari scaroo at 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?

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).