Package: gimp
Version: 1.1.18

Name........: Michael Lee
Email.......: arcana@teleport.com
Platform....: P166, Debian Linux Potato, Wacom Art Pad II tablet
GIMP Version: 1.1.18
GTK Version.: 1.2.7


-- Other system notes:
Make sure your pen is enabled in the Input Devices dialog to
either screen or window.  The problem occurs in both cases.
--

-- Problem description:
When dragging a floating selection using the wacom tablet
(don't know about others), the gimp at some point stops
moving the selection even though the stylus is still down
and the gimp reports that a move operation is still in
effect.
--


-- How to repeat:
Bring up a new image
Select a region with the pen
Drag it (the floating selection should stop moving at some
point.  The length of time for this to happen is between
miliseconds to a second or two).
--


-- Other comments:
This bug occurs when the wacom stylus is enabled to screen
or window.  If I disable it so that the pen operates like a
core pointer, everything is okay.  Dragging with the mouse
also works correctly.
--




------- Additional Comments From arcana@teleport.com 2000-03-05 20:23:34 ----

Subject: More reproduction info reguarding floating selection drag
From: Michael Lee <arcana@teleport.com>
To: 6901@bugs.gnome.org
Message-Id: <38C30896.9AD2009C@teleport.com>
Date: Sun, 05 Mar 2000 17:23:34 -0800

I tried dragging really slowly.  I noticed that the gimp loses the
selection right after the selection's image is moved.

So, when your dragging only the selection frame is moved and then at
some point, the gimp updates the visual component.  That's the moment
when the gimp loses hold but still thinks it is in move mode.

I hope this all helps,
Michael




------- Additional Comments From arcana@teleport.com 2000-05-07 01:44:24 ----

Subject: Seems to be fixed.
From: Michael Lee <arcana@teleport.com>
To: 6901@bugs.gnome.org
Message-Id: <391502B8.52A5A30A@teleport.com>
Date: Sat, 06 May 2000 22:44:24 -0700

I just tried dragging a selection around using my wacom art pad II.  It
never let go of the selection once.  I was checking my computer's
interrupt settings and it appeard that both ttys0 and ttys1 were using
irq 4 instead of 4 and 3 respectively (that's what happens when you let
the motherboard auto select ports and irq's).  I'm surprised that the
pen ever worked with a shared irq.  It does seem more responsive then
before though.

As far as I'm concerned, you can close this bug.




------- Additional Comments From arcana@teleport.com 2000-05-20 19:14:37 ----

Subject: Oops.  Disregard the last message.  It isn't fixed.
From: Michael Lee <arcana@teleport.com>
To: 6901@bugs.gnome.org
Message-Id: <39271C5D.B3A6B80F@teleport.com>
Date: Sat, 20 May 2000 16:14:37 -0700

As it turns out, I was using the pen as a core pointer which makes
dragging a selection work properly.  I just re-added my wacom pen and
wacom erase devices back into gimp and drag selection does not work. 
Hmm. Can you monitor the operation being performed and use the core
pointer version of the pointer when it is more appropriate?  That seems
like it would fix the bug.

-Michael




------- Additional Comments From gosgood@idt.net 2000-11-27 08:08:32 ----

Subject: #6091 Remarks
From: "Garry R. Osgood" <gosgood@idt.net>
To: 6901@bugs.gnome.org
Message-Id: <3A225CD0.7DE92B02@idt.net>
Date: Mon, 27 Nov 2000 08:08:32 -0500

All,

I believe #6901 "Can not continually move a floating selection with
a pressure sensitive pointer." is very nearly intractable.

1) The Xlib Programming Manual notes that for the core pointer,
   when PointerMotionHintMask is set, only one motion event will be
   sent per change of position of the mouse (Appendix E, "Event
   Structure Members" discussion of "is_hint" flag). The corresponding
   guarantee is not made for XInput events. This weekend (11/24 -11/26/2000)
   I used xscope to monitor the client/server traffic at the X protocol level.
   For Wacom tablets using the Wacom 4.5.0 driver, hinted motion reporting
   is confined to one motion event per change in some button state, giving
   rise to the behavior reported in #6901.  There is no indication that this
   is anything other than Wacom driver specific behavior; other drivers may
   cut more closely to core pointer behavior, but since the XInput Extension
   document furnishes very little guidance about what driver writers should do
   with the hint, a wide spectrum of hint behavior is possible.
   (being a "hint" there is no obligation for driver writers to
   honor it, and hinters should not make too many assumptions about particular
   behavior resulting from the request).

   Without uniform behavior, there is very little in the way of a common
   approach that Gimp or GTK can take after requesting hinted motion from
   a device. Large gobs of "if (this) {...} else if (that)..." dance before
   me eyes.

2) The only tractable approach that occurred to me was to abandon the hint
   request approach (i.e., remove GDK_POINTER_MOTION_HINT_MASK in any event mask
   flag of gdk_pointer_grab() where edit_selection tool methods may follow).
   This avoids variable behavior surrounding motion hinting with external devices.
   While Adam Moss had furnished an event queue trimmer to telescope the resultant
   flood of motion events, the underlying gdk code does not just manage a
   client side "GDK event queue" but issues XPending() to flush possible events from
   the server; much I/O waiting occurs on the gdk_event_get() call because
   of this. (see gtkutil_compress_motion() cursorutil.c Line 509). I found
   the results fairly sluggish (but not as sluggish as shunting
   gtkutil_compress_motion() and mindlessly processing every motion event).

3) An approach that I did not try runs along the line of
   changing the compression strategy of gtkutil_compress_motion() so that it
   rejects any motion event where a x*x + y*y - (x +dx)*(x +dx )- (y +dy)*(y +dy)
   delta is less than a pre-set difference. Such a filter is applied to all
   motion events. This may be a bit radical this close to the Fabled 1.2 Release.

Observations?  Suggestions? (Adam?)

Be good, be well

Garry


PS #6901, by the way, bears no particular relationship to #10498, apart from
   the happenstance of being tablet-based. That bug stems from GTK+
   bug #32617, which inserts an unrequested button-press event flag
   in gdk_pointer_grab() for XInput devices only.




------- Bug moved to this database by debbugs-export@bugzilla.gnome.org 2001-01-28 10:49 -------
This bug was previously known as bug 6901 at http://bugs.gnome.org/
http://bugs.gnome.org/show_bug.cgi?id=6901
Originally filed under the gimp product and general component.

The original reporter (arcana@teleport.com) of this bug does not have an account here.
Reassigning to the exporter, debbugs-export@bugzilla.gnome.org.
Reassigning to the default owner of the component, egger@suse.de.