Window position portal

[orowith2os]

A minor complaint some devs have with Wayland is not being able to self-manage windows, due to Wayland's security model. Such a protocol was denied in https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/72:

Wayland will not blindly add protocol features just because X11 has them. X11 has many flaws, and allowing clients to pick their global position is one of the flaws.

This issue would add a window position portal, used by apps to request to be started in a specific position on the compositor. I believe most of the details needed are already available on the Wayland side (discovering displays, available positions. Could be wrong), so all that needs to be done is a portal for requesting a different startup position, or general self-positioning.

Such a portal could also be expanded to include general display tasks including mouse positioning (#880), but that is best to be debated.

A portal would work as follows:

• Application views all available outputs and possible positions
• Application chooses a position it wants to start in
• User is notified through the portal and can tweak where the app should start, and if it should be able to move itself.

I believe that should cover the use case that mpv has here? It could also put Wayland on par with X11 in terms of wanted features.

[GeorgesStavracas]

My first reaction seeing this and spending no more than a few seconds pondering about it is that desktop portals aren't the dumping ground of unimplemented X11 behaviours. I don't think we should be adding window positioning to xdg-desktop-portals.

[orowith2os]

This feature was also denied in upstream Wayland-protocols, what should be the process for X11-like behaviours that people might want in Wayland? A third-party set of Wayland protocols for those behaviours? So you'd have the core, additions to the core, and another set for X11-like behaviour.

[GeorgesStavracas]

The process is, suggest a protocol to Wayland experts, and discuss it with them. The Wayland model is not the X11 model, as is explained in the issue that you linked, and there is no intention to replicate these behaviours. The ticket you linked also provides suggestions to how the use cases described should be implemented. There are ideas for Wayland protocols addressing some of the bullet points you put here, but not in the way X11 did. At some point, apps will need to adapt to that. If they cannot adapt due to not having protocols to describe what they want to achieve, these protocols need to be discussed and implemented. Window management is off-limits for desktop portals, that's compositor business. Sorry.