Re: GDK and XInput

[Garry R. Osgood]

Simon, Raphael, All...

I have attached a patch to gtk+-1.2.8/gdk/gdkinputcommon.h 
that modifies gdk_input_common_find_events() so that it
will simply select device-specific event classes, given
an  event_mask of GDK_XXXX_MASK values, without imposing relationships
among events. Ants march. I no longer see diversionary menus fly in my
face, and gimp otherwise seems to work well on the SGI's and the Linux
laptop. I'd appreciate it if any sufferers of #10498 could try it out
and see (1) if #10498 goes away and (2) brand new strangeness
does not arise in gimp or other applications. Post feedback/problems
here. I'd like to submit this (or something very much like this),
2000-11-22, to the GTK+ crew.

The GTK+ bug describing this GTK+/GDK issue, which #10498 
has a dependency on, is #32617 
"gdk_pointer_grab() Behaves Differently for X Input Events"

Austin Donnelly wrote: [Fri, 17 Nov 2000 15:07:29 +0000]

>> We would like a new GTK release for one other reason: the g_io_channel
>> handlers needed an new error code, and we supplied TimJ with a patch
>> to implement this.  Having this in GTK would mean we can get rid of
>> the mega-evil hack in the Gimp's g_io_channel use.  Has that patch
>> gone into GTK yet?

I saw no evidence of a GTK bug report covering this in the gnome database/gtk+ list.
I recall that you and Tim discussing it at Berlin last summer; is the 
gio_channels patch being handled informally?

Marc Lehmann wrote: [Fri, 17 Nov 2000 19:16:01 +0100]

>> > 1) Document, warn, but otherwise ignore the problem.
>> >
>> Probably the only viable way to go for 1.2, unless gtk+ can be fixed in
>> time. Maybe the best thing would be to issue a warning dialog ONCE.
>> >
>> > 3) Re-engineer select tool code to be more robust in button
>> 
>> That's out of the question for 1.2, I think.

I lean toward 1), since a tentative patch is in hand, I feed no motivation
to do complicated things at the gimp level. I have no idea how long
this patch (or something like it) migrates into production. The largest
concern I have in that regard is some application having a dependency
on old gdk_input_common_find_event() behaviour.

Be good, be well

Garry
--- /alice/WorkSpace/gtk+-1.2.8/gdk/gdkinputcommon.h-orig       Sat Nov 27 02:51:24 
1999
+++ /alice/WorkSpace/gdkinputcommon.h   Sun Nov 19 14:09:36 2000
@@ -315,18 +315,17 @@
   XEventClass class;
   
   i = 0;
-  /* We have to track press and release events in pairs to keep
-     track of button state correctly and implement grabbing for
-     the gxi support */
-  if (mask & GDK_BUTTON_PRESS_MASK || mask & GDK_BUTTON_RELEASE_MASK)
+
+  if (mask & GDK_BUTTON_PRESS_MASK)
     {
       DeviceButtonPress (gdkdev->xdevice, gdkdev->buttonpress_type,
                             class);
       if (class != 0)
          classes[i++] = class;
-      DeviceButtonPressGrab (gdkdev->xdevice, 0, class);
-      if (class != 0)
-         classes[i++] = class;
+    }
+
+  if (mask & GDK_BUTTON_RELEASE_MASK)
+    {
       DeviceButtonRelease (gdkdev->xdevice, gdkdev->buttonrelease_type,
                           class);
       if (class != 0)