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)
