wl_shell_surface_resize semantics

[Kristian Høgsberg]

On Wed, Dec 7, 2011 at 5:56 AM, Daniel Stone <daniel at fooishbar.org> wrote:
> 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.

We don't actually have to do that.  Run gtk-demo under xscope, click
the resize-grippy in the window a few times, then grep the log for
"EVENT: Button".  Only button presses are delivered to gtk+ and it
manages alright.  The wayland move and resize (and dnd) semantics are
based on the idea of transferring ownership of the grab to the
compositor.  As such, the compositor takes over the implicit grab the
client has on the pointer and until the grab is over, the client wont
receive any more events.  The behaviour is modelled on
_NET_WM_MOVERESIZE, which works in much the same way, except in X, the
WM explicitly grabs the pointer, which overrides the implicit grab.
Also, since in Wayland, the compositor can track the location, time
and button of when the implicit grab started, the client only needs to
provide the input device and the timestamp of the grab (the button
down time) to make sure we're not using a later implicit grab.

As the resize starts, the compositor sends focus out, and that could
trigger gtk+ to reset its button state, but we probably want an
explicit resize-done event as well.  In case the client draws resize
hints (such as a "width x height" tooltip during resize), it needs to
know when to pop that down.

>> 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.

When the move/resize/dnd finishes the pointer enters the surface again
(if it's still over the surface, may not be the case for dnd) and the
enter event carries the new position.

Kristian