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 168516 - Can't create guides with tablet on Windows
Can't create guides with tablet on Windows
Status: RESOLVED FIXED
Product: GIMP
Classification: Other
Component: User Interface
2.2.x
Other Windows
: Normal minor
: 2.2
Assigned To: GIMP Bugs
GIMP Bugs
: 304291 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2005-02-25 16:11 UTC by andy
Modified: 2008-01-15 12:48 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Workaround inability to create guides with tablet on Windows (1.56 KB, patch)
2005-09-07 20:26 UTC, Robert Ögren
none Details | Review

Description andy 2005-02-25 16:11:52 UTC
Distribution/Version: XP

using windows XP on a here-intern-have-a-laptop 500mhz ibm thinkpad
have just downloaded 2.2.3 (latest windows binary) and the following persist
when using my tablet (Wacom Graphire3 4x3)
I don't know if the issues have been resolved in 2.2.4 but I have seen nothing
even vaguely resembling them in the bugfix lists, so I will file this under
2.2.4 anyway. I am new to bugzilla, so if this is a naughty naughty thing, then
I will refile the entry as 2.2.3

first, and most obvious, is an inability to use my tablet to create guides
it selects the Move tool, as using the normal mouse does, when I click on the
ruler, but does not let me drag guides out of the ruler

second, more irritating but possibly more difficult to solve, is the way Gimp
handles the multiple input devices that my tablet represents
I do not use the tablet-mouse at all, for starters
I also do not use the normal mouse at all, except for creating guides
my major struggle is that when the tablet is inactive, Gimp automatically
switches back to the mouse as its input, even though the mouse is not receiving
any input
this results in loss of curves, selected paths, and other annoyances any time I
lift the stylus too far from the surface of the tablet while my cursor is over
the image or tool settings
my suggestion is that no input switching is done unless a device receives input,
so that simply lifting the stylus briefly does not trigger a change
this happens inconsistently, apparently only when lifting the stylus slowly
enough for the change to be registered

it would also be nice if I could disable the seperate settings for a particular
input device, such that it simply uses whatever settings were in use by the
previous device, so that similar problems would not be caused by slight bumps of
a mouse or other device
but that's bordering on feature request
Comment 1 andy 2005-02-25 16:13:34 UTC
when I have my new system up and running I will find out if the issues exist on
a native linux build, assuming my tablet will work
Comment 2 Bryan Kilian 2005-04-17 05:17:49 UTC
I would like the same "feature". GIMP should keep the same input device unless
it receives input from another. I don't even have a USB mouse installed on my
system, and it always switches to the mouse cursor when I lift my tablet pen and
loses what I was doing.
Comment 3 Sven Neumann 2005-04-17 11:43:52 UTC
Brian, this is not some feature you are missing, it is simply a bug somewhere in
the wintab support in gtk+/gdk. This bug report is not going to change anything
about it. It should be reassigned to gtk+ and some Windows users with a tablet
should help the gtk+ developers to sort out the issues with tablets on Windows.
Comment 4 Sven Neumann 2005-04-17 11:48:02 UTC
Andy, can you try again with the latest gtk+ and gimp builds and report back if
your problem still persists. We can then reassign the report to the gtk+ product.
Comment 5 Michael Schumacher 2005-05-25 10:10:06 UTC
Andy, any news?
Comment 6 andy 2005-05-27 07:37:27 UTC
(after finally getting logged in again)
I'm just now using the tablet on *my* laptop, a fairly old latitude c600 with Gentoo
Let me just load up Gimp (2.2.6 now) and see what we have...
The guides work beautifully, much to my pleasure.

I actually suspect now that part of the other problem may have been the hardware
on the other laptop, if the touchpad were sending small signals to the system
constantly (or the eraser stick, which I hate and suspect is the real culprit)
it would have that effect.. so, there needs to be a way to disable core input
devices from being unique inputs as well as disabling extended inputs, to
prevent losing tool settings and the like when you lift the stylus too far off
the tablet

As for windows, I don't have a windows machine available for testing any more,
except one which I wouldn't trust any results from tests run on it. That machine
is used as a holding cell for downloads, mostly...

just a side comment, I occasionally have my cursor lock up when I click
immediately after a long paint operation (airbrush, ink, etc)
irritating as it makes it difficult to work naturally.
Comment 7 Sven Neumann 2005-06-27 12:32:50 UTC
What are we supposed to do with this report then? Can it be closed?
Comment 8 Michael Schumacher 2005-07-07 16:15:46 UTC
Comment #6 seems to include some enhancement requests, but they should be raised
in new reports if desired. NOTGNOME seems to be a suitable reolution for this bug.
Comment 9 Robert Ögren 2005-09-07 20:23:06 UTC
Reopening as I can reproduce the first issue mentioned in this bug report, see
also http://gug.sunsite.dk/forum/?threadid=3322

As I also said on the forum thread: What basically happens is that when creating
a guide by dragging from the ruler, the move tool receives a spurious button
press event due to one or more limitations in the GTK+ win32 tablet code, and
that makes GIMP stop creating the guide. I will create a bug report for GTK+
about this, but it looks nontrivial to fix completely in GTK+.

There is however a rather simple workaround that can be implemented in GIMP:
Enable extension events for the rulers. This will avoid the duplicate press
events and creating rulers work nicely for me. I'll attach a patch for GIMP HEAD
that does this. 

The second issue mentioned in this bug report, GIMP switching to the mouse
device when lifting the pen, has been fixed in GTK+. See bug #167000.
Comment 10 Robert Ögren 2005-09-07 20:26:57 UTC
Created attachment 51935 [details] [review]
Workaround inability to create guides with tablet on Windows

Here's the patch that implements the workaround. I've tested it on GIMP HEAD
only, but the workaround will probably work for gimp-2-2 as well. Tested with a
Wacom Graphire 3 tablet on Windows XP.
Comment 11 Sven Neumann 2005-09-09 09:33:07 UTC
The patch should be tested on Linux (with mouse and tablet) and if it doesn't
break anything, the patch should go into both branches.
Comment 12 Robert Ögren 2005-09-26 20:30:22 UTC
I did a quick test on Linux with GIMP HEAD, X.Org 6.8.2 and the same hardware
and saw no breakage with the patch. I can do some more testing later if you wish.

Another option would be to wrap the workaround in an #ifdef G_OS_WIN32 or similar.
Comment 13 Sven Neumann 2005-09-26 20:55:15 UTC
Thanks for the patch and the testing. Applied to both branches. Closing the bug
as fixed, asking the bug reporter to open a new report if the other problems
remain (and aren't reported yet).

2005-09-26  Sven Neumann  <sven@gimp.org>

	* app/display/gimpdisplayshell.c (gimp_display_shell_new): applied
	patch from Robert Ögren that works around problem creating guides
	with a tablet on Windows by enabling extension events for the
	rulers.  Fixes the first problem described in bug #168516.
Comment 14 Sven Neumann 2005-09-27 15:05:45 UTC
*** Bug 304291 has been marked as a duplicate of this bug. ***