This commit adds protocol additions making it possible to reposition an already mapped popup.
Repositioning can be done in two ways: implicit and explicit.
Implicit popup moving is done by setting a adjustment flag on the positioner used to create it that will cause the compositor to adjust the position as the conditions used to constrain it change.
These changes may include, for example, changes in the position of the parent window or the geometry of the work area. To allow the client to update its content in response to the updated position, the client must ack the configure event, optionally with new content. Until the client acks this configure event, the existing positioner will continue to be used.
Explicit popup moving is done using a new request on xdg_popup: xdg_popup.reposition. What it does is change the parameters used for positioning a popup by providing a new xdg_positioner object. This request is coupled with a new event; xdg_popup.repositioned, sent together with the configure events (xdg_popup.configure and xdg_surface.configure) to notify about the completion of the reposition request. The reposition request also takes a token that is later passed via the repositioned event; this is done so that a client may determine for which reposition request the compositor has sent configure events.
Both these methods by themself are racy regarding inter-surface synchronization. In order to avoid race conditions when applying new states, a new request is also added to xdg_surface: xdg_surface.sync_with_popup. This request is a one-shot request to defer application of the to be committed surface state until the state of the passed popup surface is applied. The synchronization request is done on the parent, as the compositor may want to make use of the state committed on the parent to calculate the appropriate position of the child popup.
Lastly, a request to couple a xdg_positioner object with a configure event is added in order for a compositor to pair a popup reposition request with a pending configure event. This is necessary to, for example, properly constrain a popup given a yet-to-be-applied parent state. An example of when this may be necessary is an interactive resize where both the toplevel position and the relative popup position changes.
Changes since the ML version:
- Clarified that previous xdg_positioner properties are discarded when repositioning
- Make a note why the synchronization request is on the parent, not the child.