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?
