Absolute margin values pose a problem if you want to place a surface
certain distance away from a screen edge (in percents) but you also want
the compositor to place the surface on the active output.
At the moment, this issue is worked around by using kwin dbus api to
query the active output. This is not good.
This change is a take on allowing to specify margin values in percents.
It can be used to drop a dbus call in krunner and assist us with porting
other components to layer shell, e.g. OSDs, they also need to be placed
one third away the bottom screen edge.
Instead of telling it in the construction after forcing the window
creation, install an event handler that sets it when we get the
PlatformSurface event.
It has the advantage that it will also trigger in subsequent platform
surface events (e.g. after hide and show).
Making it possible for clients to call setDesiredSize directly,
The idea is that under Wayland, the panel calls this intead of setGeometry,
not trying to set an abosulute geometry that might cause the panel sized wrongly,
but just sets an hint which will ensure the panel won't overlap another one
used by https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/5437
CCBUG:489703
Otherwise we get the following error message:
Property "margins" with type "QMargins", which is not a value type
Signed-off-by: Victoria Fischer <victoria.fischer@mbition.io>
This code was designed to make sure we didn't commit new buffers whilst
we were waiting for a configure. The way this worked failed in 6 after
kwin does not reply to desired_size changes immediately.
It is uneeded after kwin commit "wayland: Avoid rearranging layer
surfaces when wl_surface size changes" which means if we do submit
frames between size change requests, they'll be ignored. Meaning the
client will eventually get a configure event at the right size.
Depending on code path taken, geometry.size() == m_pendingSize can
produce incorrect results.
If a configure event is applied, it's fine.
If the window is resized by user, m_pendingSize will have outdated value,
and setWindowGeometry() can ignore future size updates that are valid.
In hindsight, we need special hooks in the QWaylandWindow to request and
apply new geometry. Rather than have one function that deals with all cases.
When a resize is driven client side we wait for the compositor to have a
chance to reconfigure us before submitting the next frame.
Using a blocking round trip caused an issue. Instead block isExposed and
trigger an expose event whilst a sync is in progress.
Qt's resizing is inherently synchronous. When an application calls
QWindow::setGeometry with a new size, we expect it to make that resize.
An expose event of the requested size will be generated.
Wayland is by default async, a client requests a size, and then will be
configured to that size, or potentially another size.
The simplest way to map the two APIs is to roundtrip when the client
wants to resize. This way we can guarantee that a call to
`setGeometry(); update()` will have the server configured size before
the paint.
In practice it's still not perfect due to other issues, but at least
will sort itself out within a frame.
