Re: xfwm4-wayland: wlroots branch merged into wayland branch

Hello there,

> The compositor-and-helper-client approach works fine for the tabwin, but it may have limitations when attempting to port server-side decorations. I suppose copying the X11 approach could result in a lot of pointless back-and-forth between the helper client and server. How could I port xfwm4's window decorations code to Wayland?

You can render that in the compositor, thats what sway does.

> Also, window thumbnails may be a very difficult problem. There isn't even an agreed way to do that on Wayland. Should the compositor render the thumbnails, or should it pass the window's buffer to a client? Or another way I haven't thought of?

There's the foreign-toplevel-managment [1] protocol that could help you achieve
that. It's based on the wlr-foreign-toplevel-managment-unstable-v1 [2] protocol
from wlr-protocols, wlroots has support for it already.

> My compositor currently consists of two binaries. I suppose if I wanted to make it one binary, the GTK code would have to be removed as afaik you can't do GTK server side? I don't necessarily want to make it one binary.

Usually compositors do a server and a helper binary that sends commands over
an IPC socket, like swaymsg [3] does. The messages a proper to the compositor.

What stops you to do GTK on the server side? Do you need input from the user?

Cheers,

Simon

[1]: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/156#note_1697279
[2]: https://gitlab.freedesktop.org/wlroots/wlr-protocols/-/blob/master/unstable/wlr-foreign-toplevel-management-unstable-v1.xml
[3]: https://github.com/swaywm/sway/blob/master/swaymsg/swaymsg.1.scd