Re: GDK and XInput
Raphael Quinet wrote: > I tested this patch yesterday with my Wacom ArtPad II and as I > expected, it had no effect. The problem with the ArtPad II (at least > with the XFree86 driver) is that it generates proximity in/out events > that switch between the pen and the eraser when the pen is down and > the side button is pressed. This causes the Gimp to switch to a > different tool and this messes up the undo stack, among other things. > Since this ArtPad II bug shadows the GTK+ bug that you have fixed with > your patch, I have not seen any changes in the Gimp or any other > application that I tested. I did a grep on all gdk_pointer_grab() in gimp/app; not one call requests proximity events during grabs, so even if XFree86 has reason to generate them, they will be supressed on the X server side during grab periods. But you are seeing them in the event stream to your Gimp image window? -- strange... (deep ponder mode) I have XFree86 on the laptop, if I can grab an older ArtPad II from somewhere... > More testing is needed, by people who have another type of tablet. Agreed. One or two is not sufficient, and patch authors suffer from hubris ;) > Your patch looks good and should probably go into gtk-1.2.9 if it does > not break anything (alas, I cannot test this). If this fixes #10498 > for everybody except the ArtPad II users, then it may be better to > close #10498 and open a new bug report that deals with the ArtPad II. > What do you think? I received a prompt reply from Owen Taylor following my submission of GTK+ bug report #32617, however, there is not complete buy-in from him that it is a GTK problem. See http://bugs.gnome.org/db/32/32617.html. (My response to his feedback is not posted yet: 21:43 EST (-5.00)) Thank you for the report. Not too many are testing this, which gives rise to an old saying: There are two kinds of software. 1. The kind everybody hates 2. The kind nobody uses. Could it be that actually activating X Input is so frustrating that people do not use it? Is core-pointer emulation mode the typically comfortable way to use a tablet with the Gimp? Be good, be well Garry
Re: GDK and XInput
On Sun, 19 Nov 2000, "Garry R. Osgood" <[EMAIL PROTECTED]> wrote: > 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__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. I tested this patch yesterday with my Wacom ArtPad II and as I expected, it had no effect. The problem with the ArtPad II (at least with the XFree86 driver) is that it generates proximity in/out events that switch between the pen and the eraser when the pen is down and the side button is pressed. This causes the Gimp to switch to a different tool and this messes up the undo stack, among other things. Since this ArtPad II bug shadows the GTK+ bug that you have fixed with your patch, I have not seen any changes in the Gimp or any other application that I tested. More testing is needed, by people who have another type of tablet. Your patch looks good and should probably go into gtk-1.2.9 if it does not break anything (alas, I cannot test this). If this fixes #10498 for everybody except the ArtPad II users, then it may be better to close #10498 and open a new bug report that deals with the ArtPad II. What do you think? By the way, while testing what happens when the Gimp switches between different tools while you are dragging the selection, I managed to get some strange results besides the usual corruption of the undo stack and the vanishing marching ants: I had the rectangular selection tool active (as seen in the toolbox and the tool options dialog) with the context cursor of the blend tool. The pen was configured to use the selection tool, and the eraser was configured to use the blend tool. Dragging the pen with the side button pressed caused the Gimp to switch between the two tools very quickly (because of the dozens of incorrect proximity in/out events) and when I stopped, the cursor was not matching the current tool. And the image was corrupted with no chance to undo this mess, but this is usual... ;-) -Raphael
Re: GDK and XInput
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__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 +]
>> 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)
Re: GDK and XInput [Was: Re: Thanks for Tablet Testing]
On Fri, 17 Nov 2000, "Garry R. Osgood" <[EMAIL PROTECTED]> wrote: [...] > It is not clear to me why "button state" matters to GDK or > why GTK+-1.2.8/GDK requires events to be linked in this > fashion -- for XInput Extension devices only. Maybe because some other application with which GTK+ was tested (an earlier version of Gimp?) was confused if the number of button release events did not match the number of button press events? > To the contrary, Gimp' family of selection tools require the > alternate circumstance: that during the grab, button press > events cannot be permitted to arrive, else the grand Gimp > event dispatcher, gdisplay_canvas_events() > [disp_callbacks.c], would divert Gimp process flow into a > (likely) menu dispatch. Since many menu implementations are > "tool-like", this can lead to the unloading of the current > selection tool before it has had opportunity to put its > persistent state in order -- thaw the undo stack, for > example. [...] This is even worse with the Wacom ArtPad II, as I explained in my previous message: instead of popping up a menu (causing problems when the user selects a bad option), it directly switches to whatever tool is associated with the "eraser" device. This is guaranteed to cause some problems if it switches from a selection tool to a drawing tool, and ideed I lost the undo stack after a few clicks on the button. I did not test this for a long time: seeing the "assertion failed" errors and the corrupted undo stack was enough for me to believe that the problem was serious. But I would not be surprised to find that it is possible to crash the Gimp by using the wrong combination of tools. Anyway, I have only an ArtPad II and this one has some specific problems (switching devices when the pen button is pressed) that should be investigated only after the generic problem is solved. The GTK+ bug seems to affect all tablets; the one that is specific to the ArtPad II under XFree86 is worse, but it has the same roots and I think that it would be better to solve the generic problem first. I am suprised that there were only a few replies to your request for testing. It would be interesting to get more input from people who are using other models, be it only to confirm that all tablet users are affected by #10498 (and maybe by #6901, which is annoying but not critical). [...] > In light of an (is it coming? Really?) 1.2 Release > The question I have for the group is: > > 1) Document, warn, but otherwise ignore the problem. >It affects users with a certain type of tablet hardware >and only when that hardware is being used as an explicit >XInput device. Wait for a GDK fix to remove its hidden policy? Ignoring the problem may not be wise if it is possible for those who did not read the warnings to crash the Gimp or to loose a significant amount of work because the undo stack is gone or some other strange things happened. Waiting for a GDK fix may be the best choice, as long as: - the problem is really fixed - the new GTK+ can be released in less than a month > 2) Make a Gimp level hack in the much-abused event loop to >filter button presses that originate from devices when >a grab is in effect. (not pretty -- except for possibly >being pretty lame)? The hack would be even uglier if you consider the ArtPad II, because you will have to prevent any device switching while a grab is in effect (because of the spurious "proximity in"/"proximity out" events generated by the XFree86 driver). > 3) Re-engineer select tool code to be more robust in button >press events (much work here)? ... and device switching events. Not a good option because it would take too long and may not fix all problems anyway. Let's get 1.2 out of the door first and then re-write the tools for 2.0. [...] > Thank you to Simon and Raphael for thoughts, observations, snippets > of test code. As an aside, I think Simon is correct in observing > that this bug is also related to Bug #6901, "Can not continually move a > floating selection with a pressure sensitive pointer."? I tested that yesterday and I saw that I am affected by #6901 too. I did not detect this earlier, probably because I am always using the pen for drawing and the mouse for dragging stuff around. This is interesting: when I drag a layer with the pen, the layer stops moving when the preview is drawn (it takes a few milliseconds to a few seconds) and then a rectangular outline is drawn over the preview, but offset by one or two pixels. The offset is probably due to the difference between the last two motion events. This is a solid outline, not a dashed one like the marching ants. -Raphael
Re: GDK and XInput
On Friday, 17 Nov 2000, Garry R. Osgood wrote: [...] > In light of an (is it coming? Really?) 1.2 Release > The question I have for the group is: > > 1) Document, warn, but otherwise ignore the problem. >It affects users with a certain type of tablet hardware >and only when that hardware is being used as an explicit >XInput device. Wait for a GDK fix to remove its hidden policy? > > 2) Make a Gimp level hack in the much-abused event loop to >filter button presses that originate from devices when >a grab is in effect. (not pretty -- except for possibly >being pretty lame)? > > 3) Re-engineer select tool code to be more robust in button >press events (much work here)? > > Which of these is the best line of action? Do you have other > proposals? 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? With now two reasons for a new GTK release, would the GTK maintainers consider making it? Austin
Bug severity levels (was: Re: GDK and XInput)
On Friday, 17 Nov 2000, Garry R. Osgood wrote: > If no one objects, I would like to elevate #10498 from 'critical' > to 'grave.' Through a chain of causuality originating with edit-select > not being able to perform a thaw, eventually (sometimes) there is > a fatal crash in undo. Not sure why, but grave bugs are the ones > that crash Gimp - at least sometimes. This isn't the case. "Grave" bugs are less serious than "Critical" bugs (as the adjectives suggest). "Critical" is for segfault-inducing bugs, and anything else we consider release-critical (ie bugs of this class should not be present in a stable release we make). Austin
