Re: (forw) [gtk-list] Re: one function takes the control

[Tim Janik <timj gtk org>]

On Tue, 3 Nov 1998, Aaron Digulla wrote:

> I just read this in gtk-list:
> 
> ----- Forwarded message from Johannes Keukelaar <johannes@nada.kth.se> -----
> [...]
> //I need one function that launch a dialog and only returns when this dialog
> //have been closed. The function is something like this:
> 
> You'll want to make the dialog modal (with gtk_grab_add), connect your signal
> handlers, recursively call gtk_main, then call gtk_main_quit from one of your
> signal handlers (when the user clicks the ok or cancel button, for example),
> and then the call to gtk_main will return (eventually). You'll then also want
> to call gtk_grab_remove, otherwise the rest of your application will remain
> dead.
> [...]
> ----- End forwarded message -----
> 
> IMHO, it would be *much* better if a the destroy hook of a modal dialog
> would call gtk_grab_remove() - This way, you would never lock up your
> X server (that can happen if you create a dialog which is not modal for
> the app but for the display - If you close the window and don't ungrab
> it, the whole display is locked and there is no way out. If you are
> unlucky, the keyboard won't work, so you can't even kill the X server !).

you are confusing different levels of grabs here.
an X grab for mouse events occours if you call gdk_pointer_grab() for a
mapped window. if that window gets unmapped (a window's destruction implies
unmapping of course), the grab is automatically released by the X server.
the same applies for keyboard grabs, which needs to be retrived through a
different function, which is gdk_keyboard_grab.
apart from that, gtk has its own idea of implementing grabs, for the sake
of the modal dialog implementation.
usually, all widgets in a gtk application may receive all kinds of events,
but if a gtk grab is activated (through gtk_grab_add), certain events
will only be delivered to the widget that holds the grab (or its descendants).
"certain events" means pretty much all "action" events such as key presses/
releases, enter/leave, motion notifies, button presses and proximity events.
"administrative" events, which care about keeping the GUI in sane state, are
still delivered to the original widgets that the event occoured on. these
are delete, destroy, property, expose, focus, configure, (un)map, selection,
visibility and dnd events.
in contrast to X grabs, gtk grabs have the ability to stack, so that a modal
window can popup another modal window, and when that's finished, the old modal
one is still holding its grab. this is not possible with X grabs, they will
just override existing grabs.
in any case, a gtk grab will not cause the pointer or the keyboard to be
grabbed, and thus, modal gtk windows will never stop you from working with
different apps on the same display, especially not after a gtk application (or
any X application) finished execution.
apart from that, widget destruction will care about releasing an existing
gtk grab for that widget. (gtk grabs differ further from mouse and keyboard
grabs, in that a widget can hold a grab while its not visible, since its
grab is only automatically removed if it is destroyed, not if it just
unmapped).

---
ciaoTJ