After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 6901 - Can not continually move a floating selection with a pressure sensitive pointer.
Can not continually move a floating selection with a pressure sensitive pointer.
Status: RESOLVED WONTFIX
Product: GIMP
Classification: Other
Component: General
1.x
Other Linux
: Normal major
: 1.2
Assigned To: GIMP Bugs
GIMP Bugs
Depends on:
Blocks: 127786
 
 
Reported: 2000-03-06 02:15 UTC by arcana
Modified: 2004-02-10 20:48 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description arcana 2001-01-28 15:49:11 UTC
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.

Comment 1 Raphaël Quinet 2001-04-26 18:14:27 UTC
Re-assigning all Gimp bugs to default component owner (Gimp bugs list)
Comment 2 Michael Natterer 2002-03-19 13:16:41 UTC
Fixed in HEAD, still thinking about backporting...

2002-03-19  Michael Natterer  <mitch@gimp.org>

  * app/tools/tools-types.h: added enum GimpMotionMode which can be
  one of { EXACT, HINT, COMPRESS }.

  * app/tools/gimptool.[ch]: removed tool->perfectmouse and added
  tool->motion_mode. Default to GIMP_MOTION_MODE_HINT.

  * app/tools/gimpinktool.c
  * app/tools/gimppainttool.c: set GIMP_MOTION_MODE_EXACT.

  * app/tools/gimpfuzzyselecttool.c: set GIMP_MOTION_MODE_COMPRESS.

  * app/tools/gimpeditselectiontool.[ch]: ditto. Removed
  gtkutil_compress_motion().

  * app/display/gimpdisplayshell-callbacks.c: look at
  active_tool->motion_mode and perform pointer grabbing and motion
  compression accordingly. Also, don't request motion hints from
  XInput devices because the wacom driver sends crap (fixes #6901).
  This change also brings hints and ordinary motions back in sync
  albeit compression, so IMHO it also fixes #68542 and #22375, but
  this needs further investigation.
Comment 3 Raphaël Quinet 2002-12-10 08:28:07 UTC
Setting target to 1.2.4.  If the patch will not be backported, then
this bug report can be closed as WONTFIX.
Comment 4 Dave Neary 2003-05-10 18:19:00 UTC
Suggest WONTFIX.

Dave.
Comment 5 Adam D. Moss 2003-05-10 19:33:30 UTC
Would just the don't-request-hinted-motion-from-XInput-devices part of
the fix be enough to suffice for 1.2.x?
Comment 6 Dave Neary 2003-05-21 16:26:08 UTC
Moving to 1.2.6 milestone, since it is looking like there will be a pretty quick
1.2.( release.
Comment 7 Sven Neumann 2004-02-10 20:48:30 UTC
Closing this report as WONTFIX. The change looks rather complex and
there doesn't seem to be interest to backport this change to the 1.2 tree.