wl_shell_surface_resize semantics

[Pekka Paalanen]

On Tue, 06 Dec 2011 22:48:27 -0800
Bill Spitzak <spitzak at gmail.com> wrote:

> If the code is calling something that it knows means it will not get
> the release event, then certainly the code can be further altered to
> not expect the release event, by doing *something* to GTK. At worst
> you should be able to internally generate the release event and feed
> it to GTK in some way so that it thinks things are done.
> 
> It certainly seems wrong to me to require the compositor to send
> dummy events. If you really cannot figure out a way, I would prefer
> some rewriting of GTK to fix this instead. It has to be rewritten
> anyway to call Wayland, right?

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.

IMHO, this would be logical, so I believe we are just seeing a bug in
the demo compositor.

On the other hand, a client modifying its view of the button state based
on what it requests from the server does not sound right.

But, there is another problem, see below...

> On 12/06/2011 11:28 AM, Rob Bradford wrote:
> > I've been tracking down an issue in the GTK+ Wayland implementation.
> >
> > The problem is that if you've started to resize the window using the
> > grip all future events get interpretted as a resize events even if
> > you're nowhere near the resize grip?
> >
> > The explanation: by default GDK behaviour is such that when you
> > button down on something then a pointer grab is created so all
> > motion events continue to go to the GdkWindow in which you
> > originally buttoned down in. When the button is released that
> > pointer grab goes away. However if we call wl_shell_surface_resize
> > we never get the release event and so GDK still thinks that the
> > resize window still has the pointer grab. We don't get that release
> > event because of the grab that the shell takes upon starting the
> > resize which is pretty reasonable.
> >
> > One proposed solution is to ensure that the shell and compositor
> > propagates the release event (which is currently in the grab in the
> > shell) across to the client. This would ensure that the down and
> > released events are always paired up.
> >
> > Anybody have any other thoughts?

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?

There are also other things that makes me wonder. Why does the demo
compositor remove pointer focus from the surface for the duration of the
user initiated move or resize? Is it so that it can then send a
pointer_focus event on the end of the move/resize that resets the
pointer location for the client? (You could also use this to detect
when the resize or move ends, but...)

I understand why the compositor will inhibit all motion events while a
move or resize is active: instead it sends nothing (move) or configure
events (resize). But is this necessary? Why not just relay all events
to the client as we normally (and under the usual implicit grab) do, in
addition to the configure events?

While resizing, surely we should not inhibit events from other buttons?
We are not inhibiting keyboard events, either.

What if the toolkit, say, has an "undo resize" which is triggered by
pressing another mouse button while holding the primary button down due
to resize? With the current demo compositor, the client never gets the
button events.

Ah, one more observation: I don't think the compositor is forced to send
the configure events on resize by the spec, until the final size.
Another compositor could simply stretch the existing surface image
without bothering the client, saving CPU cycles. In this scenario, the
client might be confused by the motion events - except that the client
knows it initiated the resize, and can deal with it.

Unfortunately, neither the spec nor TODO seem to mention anything about
the move and resize protocol.


Cheers,
pq