Re: NotifyUngrab handling

[Felix Bellaby <felix pooh u-net com>]

Owen Taylor writes:
 > Felix Bellaby <felix@pooh.u-net.com> writes:
 > [...]
 > Note that there is no "NotifyUngrab" event. There are
 > enter/leave notify events with a mode sent to Notify[Un]Grab,
 > but these events are not generated when the mouse
 > is over the grab window.

I was basing my comments on XUngrabPointer (3) which does not 
specify any conditions behind when it generates crossing events
with type NotifyUngrab:

       The XUngrabPointer function releases the pointer and any
       queued events if this client has actively grabbed the
       pointer from XGrabPointer, XGrabButton, or from a normal
       button press.  XUngrabPointer does not release the pointer
       if the specified time is earlier than the last-pointer-
       grab time or is later than the current X server time.  It
       also generates EnterNotify and LeaveNotify events.  The X
       server performs an UngrabPointer request automatically if
       the event window or confine_to window for an active
       pointer grab becomes not viewable or if window reconfigu-
       ration causes the confine_to window to lie completely out-
       side the boundaries of the root window.

However, this might not be the first time that the docs do not
tell the whole story...

 > > Similar effects can be generated by the Xserver spontaneously
 > > when it issues a NotifyUngrab as a result of the menu becoming
 > > obscured. 
 > 
 > Not true, you can have a grab on an obscured window. You
 > can't have a grab on a window is not "Viewable" - i.e.,
 > it or one of its parent windows is hidden. 

My mistake. (:

 > Basically, when you grab the X the mouse or keyboard, the
 > only way that any other client can cause your to release
 > that grab is by hiding your windows.

I assume that gtk+ has a mechanism for cleaning up the widget which 
had the grab in this (unusual) case.

 > > However, these are more tricky to reproduce because 
 > > the NotifyUngrab is rarely the LAST event to be recieved by the
 > > gtk app. Usually, the WM sends some other event (e.g. FocusOut) 
 > > which causes the menu system to close down. 
 > 
 > No, the only thing that causes the menu system to close
 > down is a ButtonPress or Release.

My unfamiliarity with gtk+ is showing ...

This explains why you sometimes see the menu belonging to one
app over the top of another one that has been mapped over it.
As you point out, NotifyUngrabs do not help in this case.

 > [...]
 > Now, I understand why you don't want to hold a grab while
 > waiting for SaveYourselfDone - other clients may need
 > to interact with the use. But Notify[Un]grab enter/leave
 > events don't do us any good.
 > 
 > If we want a mechanism for this, we need to invent it ourself.
 > 
 > (Actually, session management isn't the only case where this
 > type of thing comes up. In DND, when a drag starts, one
 > wants to convince the widget where the drag started that
 > it should ignore the button press event that started the
 > drag.)

Indeed, DND is a minefield of grabs.

 > Perhaps we need an GDK_ABORT_GRAB_REQUEST event which we
 > send to the window holding the grab to tell it to give
 > up the grab. But this would require quite a bit of 
 > code modification  - there are 15 uses of gdk_pointer_grab()
 > in GTK+, 9 in gnome-libs, 22 in the GIMP, etc...
 > 
 > (and it would require breaking binary compatibility to add 
 >  another event type)
 > 
 > I don't think we want to do that right now.

Agreed. This can wait.

The man page quote above suggested to me that it would not 
require quite this much work to address it. (:

 > Isn't the right thing to do just to hold up the processing 
 > of the SaveYourself message until the grab was released -
 > i.e., poll in a timeout until !gdk_pointer_is_grabbed(). 
 > 
 > (There is no equivalent gdk_keyboard_is_grabbed(), but 
 > grabbing the keyboard without grabbing the pointer 
 > is a bug, so that should not be a problem)

This was my first idea before I spotted the apparent promise of
the XUngrabPointer man page.

The problem with doing this is that the menu item selected by the
user to pop down the menu might popup a non-modal dialog which
obscures a dialog generated by another client in response to an
Interact request. (Am I right in thinking that this could happen
under gtk ?). The user would then have to move the offending dialog 
out of the way in order to continue and might easily get the 
impression that the Xserver has frozen.

I could extend the session management protocol used by gnome 
to get round this problem. Gnome apps could wait for the grabs 
to be released and then call SmcGetProperty to obtain a property 
called "GnomeSaveYourselfReady". gnome-session would wait 
until all the clients in the session save had requested this 
property before returning a value of "Confirmed". I can use
other properties to signal support of this protocol extension.

I will explore this as a solution but not in gnome-1.0.
Perhaps, gtk will have a solution by then. (:  

Thanks,

Felix