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 wa
On Tue, 6 Dec 2011 17:36:36 -0800
Bill Spitzak wrote:
> Making a switch that passes all *remaining* arguments to the shell
> would be better because it avoids quoting issues and makes it
> trivial to edit a call to the shell into a call to the compositor.
>
> Ie:
>
> wayland-compositor -
Making a switch that passes all *remaining* arguments to the shell
would be better because it avoids quoting issues and makes it trivial
to edit a call to the shell into a call to the compositor.
Ie:
wayland-compositor -x -y -b blah -x bar
This makes the compositor get the -x and -y swi
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
