wl_shell_surface_resize semantics

[Daniel Stone]

Hi,

On 7 December 2011 08:15, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> I see the problem from a completely different point of view, similar to
> Rob.
>
> If we (the compositor) send a button press event to a client, we better
> be sending a button release event, too. Otherwise the client view of
> button state will be incorrect. It will not be a dummy or a faked
> event, it should be the real button release event, that would be sent
> to the client anyway if it was not resizing. The implicit grab on button
> press in the compositor is (AFAIU) supposed to guarantee that.

Absolutely.  We always need to guarantee consistency: every button
press event must be matched by an explicit button release event.  We
cannot rely on clients to infer the event and generate their own fake
events, because they can and will get it wrong, and it'll be a pain in
the neck to debug.

> The problem with relaying the button release event is, that the event
> does not contain coordinates. Client is supposed to track coordinates
> via motion events, and it will currently(!) not get those for resize
> (nor move). Should we fake a motion event prior to the button release
> event that corrects the client's view of pointer location?

Yep, warping the pointer seems sensible to me.

For compositor-handled resize, I think this would be something like
the ideal flow:
  * button pressed
  * compositor sends button press event to client
  * client requests compositor handle resizing
  * compositor takes over grab handling, sends button release event to
client, noting through a flag that it's a cancel event rather than a
physical button release event
  * compositor handles resizing, optionally informs client through the
resize process of the new size
  * button released
  * compositor sends pointer motion event to new co-ordinates, informs
client that resize process has finished

Cheers,
Daniel