Draft: Add xdg-alignment protocol for window-placement control

Hi there!

This protocol is a follow-up from !247 (closed) and addresses the same usecase, please have a look at that MR to read about applications that would use it.

In brief, the protocol allows clients some degree of control where their windows end up on a Wayland compositor output. Some people have voiced concern that now every Wayland compositor might have an absolute coordinate system. While that is certainly true, and while I would assume such compositor to simply not implement the output-relative positioning protocol and such apps to not play well with these compositors anyway, I also thought it was a good idea to explore how a potential alternative would look like.

There are three scenarios which such a protocol needs to address:

• Main window + multiple toolboxes (e.g. multi window GIMP)
• Multiple windows on different outputs in relation to each other
• Window arrangement profiles that the application can save & load

Here's a short summary how each of these are addressed:

Multi-Window MDI applications (IDEs, GIMP, DAWs, ...)

1. The application creates a new main window and calls set_output_anchor for it with e.g. top as anchor value
2. Compositor places the window at the top of the current output
3. Application creates secondary windows, e.g. toolbars, and calls set_relative_position for each of them, placing the window in relation to the geometry origin of the first-placed window.
4. The application UI is shown as expected.

Windows placed in relation on different monitors

1. Client has a main window on output A
2. Client creates a buffer-less new window, calls set_output on it to place it on output B with anchor top_left
3. Window is displayed on output B
4. Client uses set_relative_position on the newly placed window on output B to place all other windows in relation to the new on in the top-left corner

Window layout profiles

1. User arranges application windows a certain way, and wants to save that layout to quickly load it later and switch between window arrangements in the app. The user clicks "save".
2. The client calls get_geometry_token on every toplevel window which should have its position and dimensions restored at a later time.
3. Compositor replies with geometry_token events, one per each window, providing the client with opaque "tokens" that it can "redeem" later to restore a window position to its previous place.
4. Client saves these tokens for the current profile.
5. User rearranges windows for a different usecase, wants to reload the old layout and instructs the application to restore the old window layout.
6. Application retrieves all tokens it has previously received from the compositor, and calls set_get_geometry_token on the respective windows for each of them.
7. Compositor receives the previously-known tokens and restores the old positions, unless other policy overrides this application preference.

This protocol is way more complicated, but it does not require a global coordinate system and should even work with VR compositors. The one usecase which is does not fulfill is the case where the UI is constructed from multiple executables, as an application can only arrange windows in relation to its own windows. I could imagine ways to make that work using the token system though, but it would require some care (and tokens would need to be valid for all apps in that case). In order to keep this example protocol small, I haven't included that.

The multi-process usecases is also somewhat rare compared to the others, the best use would probably something like a Python IDE wanting to show Matplotlib windows of an external Python process in a certain spot.

Anyway, this is the alternative that should work for maybe 95% of such apps, still better than 0%.

What do you think? ;-)

(Obviously the name of this protocol can be changed, "positioning" would be much better than "alignment", but I do not want it to conflict with the other MR while that one is still active)