I feel configure events and requests are messed up

[Giovanni Campagna]

Currently, moving and resizing a window works with two requests (move
and resize), that are only concerned with starting WM operations, and
one event (configure), which is only emitted if the WM itself is
resizing the window, and toolkits are allowed to ignore.
This results, at least in libtoytoolkit, in a great complexity when
dealing with resizes, as it basically impossible to compute the right
size of a surface without accessing the underlying buffers (possibly
through a hack called wl_egl_window_get_attached_surface).
I believe this is one of the features X11 / ICCCM got almost right (I
say almost because there are some problems with reparenting, but we
don't have that). In X11, as you know, there are three requests:
_NET_WM_MOVERESIZE, ConfigureRequest and ConfigureNotify.
The client may at any time request a new size (which is needed for
toolkits that do width-for-height), but the only one that matters is
that included in the last received ConfigureNotify, which correctly
gives the WM the ultimate power of deciding the window size, and gives
the client a consistent way of knowing it.
Plus it doesn't overload the attach request (a painting operation) with
semantics like position and size, that also affect events.

So my view of the resizing stuff is as follows:
- one request in wl_surface, called "configure", with args:
  * width
  * height
  * gravity (specifies how to move the window, it's a hint and WM can
ignore)
- one event in wl_surface, called "configure_notify", with args:
  * timestamp
  * width
  * height
  * x
  * y
If a client receives a configure_notify event with a timestamp which is
earlier than the latest configure request, it should ignore (but wait
before drawing until the matching configure_notify event is received).
Every configure requests results in a configure_notify event, even if
the WM decides it doesn't like the new size at all (in which case the
configure_notify would have the same size).
The position passed in is not guaranteed to be the actual position used
in deriving events (there may be transformations other than translations
involved and the compositor is free to draw the window wherever it
likes). However if possible it should pass meaningful coordinates and
keep them updated if the window is moved; this is meant to support
programs doing stuff like gdk_window_get_position() or
gdk_window_get_pointer(), when the pointer is not focused to the window.
The request and the event need to be in wl_surface, rather than
wl_shell, because various libraries (egl, cogl, cairo, GDK, just to name
a few, and maybe even application code) need to track the size, and they
cannot do it from a global object.
- one request in wl_shell, called "start_moveresize", is the equivalent
of current "move" and "resize" and results in a bunch of
"configure_notify" as the user uses the mouse or the keyboard to resize
the window
- one request in wl_shell, called "move", with args:
  * x
  * y
- one request in wl_shell, called "restack", with args:
  * position (top, bottom, above, below)
  * sibling (a wl_surface, or 0 for top/bottom)
The WM is free to ignore move and restack for whatever reason, and it is
free to move and restack windows as it pleases. No confirmations are
sent.
- the attach request in wl_surface specifies the coordinates relative to
the surface (thus 0,0 in the most common case), so it's not needed to
track how the surface moved when it changed size. The client can expect
clipping to the actual surface size if it attaches a buffer which is too
big; OTOH undefined results happen if the buffer is smaller (the
compositor could extend the decoration, repeat the last row of pixels of
the buffer, draw full transparent, or keep the previous contents)
Further extensions to the protocol (read: ICCCM-like properties) will
allow for resizing in fixed steps or specifying a minimum size, that
again, WMs are free to ignore at any time. This will allow to implement
policy where it really belongs, and not in toolkits or applications.

If this is likable enough, I can prepare a patch against wayland and
wayland-demos.

Giovanni
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 316 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20110905/3c80e62b/attachment.pgp>