(I forgot to mention in the above message that I was looking at the unstable version)
On Mon, Aug 8, 2022 at 1:54 PM samuel ammonius <sfammon...@gmail.com> wrote: > Hi Daniel, > > I've just looked at the xdg-shell protocol as you said. I was really > surprised at the > amount of features it had, but one part in particular caught my eye: > > <request name="set_window_geometry"> <description summary="set the > new window geometry"> The window geometry of a surface is its "visible > bounds" from the user's perspective. Client-side decorations often have > invisible portions like drop-shadows which should be ignored for the > purposes of aligning, placing and constraining windows. The window > geometry is double buffered, and will be applied at the time > wl_surface.commit of the corresponding wl_surface is called. Once the > window geometry of the surface is set, it is not possible to unset it, and > it will remain the same until set_window_geometry is called again, even > if a new subsurface or buffer is attached. If never set, the value is the > full bounds of the surface, including any subsurfaces. This updates > dynamically on every commit. This unset is meant for extremely simple > clients. The arguments are given in the surface-local coordinate space > of the wl_surface associated with this xdg_surface. The width > and height must be greater than zero. Setting an invalid size will raise an > error. When applied, the effective window geometry will be the set > window geometry clamped to the bounding rectangle of the combined > geometry of the surface of the xdg_surface and the associated subsurfaces. > </description>* <arg name="x" type="int"/> > <----------------------------------------------- >> <arg name="y" type="int"/> >> <-----------------------------------------------* <arg name="width" >> type="int"/> <arg name="height" type="int"/> </request> >> >> Doesn't this mean that Wayland already supports this? >
