Hi,
I was delighted this weekend to uncover a cause to #10498: "Marching
Ants die untimely deaths" which has been pestering me for sometime
now. The immediate cause stems from the pause count in the Selection
structure being incremented more often than being
decremented. [selection.c CVS-1.6 selection_pause() L. 590,
selection_resume() L. 600, selection_start() L. 627]
The underlying cause to the asymmetry is a bit troubling, for which I
will need some testing help on a wider range of hardware. It appears
that when the Wacom Tablet device is active, it is possible to
originate a right mouse button event to bring forth an application
menu, for example, even when the pressure point is active (and
functioning somewhat like the left mouse button). In particular, this
behavior undermines some assumptions implicit in init_edit_selection()
and edit_selection_release() about actually seeing a left button
release. [edit_selection.c CVS 1.34]. which assumes, (mostly
correctly, perhaps) that once a gdk_pointer_grab() has been performed,
it darn-tootin' *will* see the left button release to unwind the
selection pause count and the gimp_undo_freeze() among other
interesting things.
More about that later, first I would like tablet users [and not just
Wacom tablet users] to perform a nice little torture test on their
Gimp and post results here to determine how widespread this difficulty
may be. (I think any 1.1.2x Gimp version will do, as pertinent code
areas have not changed much lately)
0. Start Gimp. New Image (Cntl-N).
[Optional: <File>->Preferences->Image Windows->Cursor Mode is "Tool Icon"]
1. Activate the tablet device.
a. <Image>->Dialog->Device Status... (handy device monitor)
b. <Image>->Dialog->Input Devices...
c. Select your tablet device (mine is named "wacom", yours may differ)
d. Switch your tablet device Mode: to "Screen"
e. Confirm: your device should add itself to the "Device Status"
display picked in step 1.a. but be inactive ("pushed out" label)
2. Pick up your pen and bring it in proximity to the drawing tablet
a. Confirm: your device should become active ("pushed in" label)
3. Conveniently, the Rectangular Select Tool is already active. Make a
selection with it.
a. Confirm: Marching Ants appear around the selection border.
4. With pen still in hand, move to the interior of the selection region.
5. Press down and move the pen (this activates init_edit_selection()
and Edit Select tool methods that over-ride the rectangular select tool-set.
also, the pause reference count is incremented in the currently active
Selection object; gimp_undo_freeze() had already been invoked
in a rectangular tool method context)
a. Confirm: Move cross icon appears. (if Cursor Mode is "Tool Icon")
6. If you have a Wacom Intuos tablet (and Grapphire too, I believe) you
have a right mouse button emulator on the pen body. Such a button
is often on pens of other models as well. Press this right mouse button
emulator now.
7. Do you obtain a right mouse button Image menu? Please report "yes" or "no"
to this news group, plus your tablet model and X Input device driver
(If you know). I have a Wacom Intuos attached to an SGI O2, and the driver
is the Wacom Tablet Driver for Intuos tablets Version 4.4.0 (SGI)
I get a right mouse button Image menu, as if I had pressed the (actual)
right mouse button in ungrabbed gdk_pointer mode. Had I omitted steps
1.a - 1.e and followed the remaining steps with either the mouse or the
pen (Device status shows "Core Pointer" active), the generation of a right
mouse button Image menu does not occur after step 5 "press down and move...".
With the pen pointer (or left mouse button) pressed, the right mouse button
appears to be ignored.
In getting a right mouse button menu (Device status shows "wacom" and it is
active), all manner of mischief is now possible, undermining the assumptions
about pointer state underlying edit_selection code. This appears to range
from:
A. no mischief at all (the right mouse button emulator is immediately
released: no menu selection is made)
B. some mischief (The button release event is missed if a menu selection
occurs. Nothing ever decrements the Selection object reference count
and -- unbalanced -- the selection remains paused until application
exit: Bug #10498)
C. Great Mischief (If the pointer moves outside the Gimp Image window after
step 5 "press down and move the pen..." then it appears that the
specialized edit-selection tool remains in control well after its designers
intended: it's edit_selection_button_release() method does not get called
in a timely fashion, gimp_undo_thaw() is not immediately called
either, so undo events can be lost if the user proceeds with further
image manipulation.
I would like to obtain a sense of how widespread this phenomenon
is. Marc Lehmann reported to this list that he observed it on Simon
Budig's machine at Systems'99, but not his own, and I believe Simon
has a tablet/driver/machine quite different from an SGI O2. [See Re:
Gimp help docs thread]]
In particular, I would very much appreciate it if Mitch Natterer can
look at this set of conditions from a UI perspective and Austin
Donnelly from an Undo/Redo perspective. Good spots to put breakpoints
are at the entrances to selection_pause() and selection_resume()
[selection.c CVS-1.6 L. 590 ff.] If this problem is reproducible on a
wide class of machines, then I think we have a bit of work ahead of us
on this.
Thank you's in advance to all,
Be good, be well
Garry
