Exploring the Need for a Standardized Window Management API within or alongside Wayland

Michael Tretter m.tretter at pengutronix.de
Tue Nov 7 08:39:49 UTC 2023

On Fri, 03 Nov 2023 09:33:10 -0700, Wayne Sherman wrote:
> Is a unified approach for window management in the Wayland ecosystem needed?
> (i.e how can the end user or system designer control the size,
> position, and layer of top level application windows).

I certainly see the use cases and probably the need for a unified approach for
more control over window geometry and stacking [0]. There already exist a few
Wayland shells and workarounds that address this issue.

> Certain applications and workflows, particularly those involving
> complex window arrangements, dynamic window resizing, and precise
> positioning (e.g., tiling window managers, graphical editing tools,
> and presentation software), can greatly benefit from having a measure
> of control over their window geometry and stacking. Currently,
> attempts at providing this are being done by a variety of
> compositor-specific protocols and extensions, which can lead to
> fragmentation and inconsistent user and developer experiences across
> different environments.  A standard API or protocol would only serve
> the needs of these applications and would also aim to prevent the
> proliferation of inconsistent and ad hoc solutions.

I think it is important to split the discussion between client applications
that would like to position their own windows, and compositors/shells that
implement predefined (by the user or system developer) rules.

Pretty much all use cases that come to my mind could (and should) be addressed
in the compositor/shell. Various compositors and shells already implement one
or another mechanism to kind of define how the windows are arranged. Usually
these are pretty limited or specific to the compositors needs.  Working
towards something unified may be a nice goal, but having something that
doesn't feel like like an ad-hoc solution or hack would be a nice intermediate
step. This would address the embedded use cases and some kind of
compositor/shell automation.

On the other hand, I think adding a mechanism for applications to control
their own windows is not reasonable. Such a mechanism either becomes too
complex and fragile to use, or to restricted for a lot of use cases.


[0] https://www.youtube.com/watch?v=qK2Emqp9t0g&t=14244s

More information about the wayland-devel mailing list