Re: NotifyUngrab handling

[Owen Taylor <otaylor redhat com>]

Felix Bellaby <felix@pooh.u-net.com> writes:

> 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...

The O'Reilly Xlib programming manual is a bit more explicit
in saying that XGrabPointer generates the events when the
grab window is not equal to the current pointer window. This
was what I had remembered from previous usage, but to
make sure, I hade to write up a little test program to check.
 
>  > > 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.

No, it doesn't. This may be the reason why one on rare occasions
sees menus left on the screen without without a grab - if
somehow the parent window is hidden while the menu is up,
this might happen.
 
[...]

>  > 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 don't think this is much of a problem, since user interaction
should be rare under most conditions. (The interact_style
should be SmInteractErrors unless the user explicitely requested
the checkpoint, and if the user requested the checkpoint, he
most likely doesn't have another menu up. Also, the serialization
of interact requests makes interaction enough of a pain, that
I suspect most apps won't bother)
 
But it does point out a few fine details that are probably
worth being noted somewhere:

 - The window manager should not freeze itself, or at least
   not until the "phase 2" save-yourself that it is supposed
   to request.

 - Interaction windows should get the appropriate GNOME wm
   hint to put them in a layer over all normal application
   windows. 

> 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 think that using the GNOME WM hints for layering as noted
above is a easier and probably just-as-good solution.

Regards,
                                        Owen