Re: motion notify question

[Owen Taylor <otaylor redhat com>]

Havoc Pennington <hp redhat com> writes:

> Hmm, I just noticed that GTK 1.2 specifies OwnerGrabButtonMask in the
> event mask for the X window, and GTK 1.3.x does not.
>
> Fri Feb 18 14:37:29 2000  Owen Taylor  <otaylor redhat com>
>
>         * gdk/x11/gdkwindow-x11.c (gdk_event_mask_table): Remove
>         OwnerGrabButtonMask from button entries for
>         GDK_BUTTON_PRESS / GDK_BUTTON_RELEASE.
>
> Owen didn't explain the issues there, he can probably do so better
> than I can.

The purpose of OwnerGrabButtonMask has to do with the implicit
grab that occurs whenever a button press is occured. It corresponds
to the owner_events parameter of XGrabPointer() - 

If OwnerGrabButtonMask is included (owner_events = TRUE), then events
that would be delivered to to the grabbing client are delivered as
normal, otherwise events are only delivered to the window which
originally received the event.

But usually - for things like a button, a scrollbar, etc, you want the
owner_events = FALSE behavior - the widget should continue capturing
events until the button was released, whether the pointer is
over another client or the same client.

So, the effect was that when you received a button press in GTK+-1.2
you had to call gtk_grab_add() to establish a GTK+ grab so
that events would continue getting delivered to your widget.
(People also sometimes called gdk_pointer_grab(), but there
are race conditions if you do that.)

However, making the explicit grab with gtk_grab_add() means that
you have to make sure that you get the button release, even
if the widget becomes insensitive, a modal dialog pops up,
etc. Otherwise, you get a stuck grab. (With gdk_pointer_grab()
its worse - you get a stuck global pointer grab and the
user can't even get to other apps.)

There are all sorts of rare bugs relating to this in GTK+
apps.

So, for GTK+-1.3, we decided to remove OwnerGrabButtonMask - there
may be a few rare cases where you want the old behavior,
but it isn't the common case, and it isn't the safe case.
If it turns out we need it, we can add a GDK_OWNER_GRAB_MASK
to correspond to the way that Xlib does it.

I hope this (probably still not very clear) explanation helps
a bit.

Regards,
                                        Owen
 
> pavel klebanov ne mediaone net writes:
> > You make a good point, but my experiments show that if you were to release
> > in another window which captures releases then the release won't register
> > in the original widget. Is this your experience, too?
> >
> > So if you are programming something like a lever, the following
> > unfortunate combination might happen. Suppose you
> > 1. Press the mouse within the lever.
> > 2. Move it outside the bounds.
> > 3. Release it over another lever.
> > 4. Then press it down elsewhere
> > 5. Move it with in the bounds of the original lever.
> >
> > As far as the original lever is concerned then is that it's been pressed
> > down and now the mouse is moving over it with the button pressed. So it
> > must react which is incorrect. The problem is that it has no way to find
> > out that it's been released and that another one has been pressed - if
> > there's no communication between the objects.
> >
> > The way I solve the problem is by enabling focus and then capturing the
> > loss of focus, but you would agree that's not very clean...
>
> I think it may change depending on GTK version, then.