wl_shell_surface_resize semantics

[Bill Spitzak]

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?

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?
>
> Cheerio,
>
> Rob
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel