(No Subject)

[Simon Ser]

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

Hope this helps,

Simon Ser