(No Subject)

[adlo]

> 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?

Regards

adlo