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
