Two problems with grabs

[Owen Taylor <otaylor redhat com>]

1) http://bugzilla.gnome.org/show_bug.cgi?id=69934

  Chris Blizzard points out the following problem:

  If you create multiple grab groups, then gtk_grab_add() in one group
  doesn't affect event going to other grab groups.

  This is normally you want for modal dialogs, but is _not_ what you
  want if you are using gtk_grab_add() in conjunction with a
  gdk_pointer_grab() with owner_events = TRUE.

  As a consequence of this, if you have multiple grab groups, menus
  won't pop down properly if click on windows in other grab groups,
  though they will if you click on different applications or other
  windows in the same grab group.

  Possible fixes:

   - Add API to allow distinguishing "global gtk_grab_add" from
     "grab group specific gtk_grab_add"

   - Do tricks so that when a grab is present with owner_events = TRUE,
     events delivered to other window groups in the same process
     are rewritten to look as they would be if they occured over
     windows in other processes. [ That is, they would have
     event->window switched to be the grab window, and coordinates
     converted to be relative to the grab window ]

2) http://bugzilla.gnome.org/show_bug.cgi?id=65006
  
 The problem here is that GtkRange/GtkScrollbar now relies on
 the implicit grab that occurs when you press a button.

 However, since for the combo popdown, there is already an explicit
 grab in place, this grab doesn't occur; this is also going to
 affect GtkButton, and any other widget that relies on the implicit
 grab.

 One solution for this would be to, in GDK, emulate implicit grabs
 even when explicit grabs are in effect. A little painful to implement
 but makes for a simple API.

 The other would be to never rely on implicit grabs if there is
 potential for the widget to be used in a "globally modal" situation,
 like a popup widget. This means

  a) using gtk_grab_add()
  b) watching ::grab-notify and ::state-changed to make sure we don't
     lose the button release.
  c) dealing with 1) [ though we have to fix 1) anyways ]