GNOME Bugzilla – Bug 723186
Dialogs are not working when using a pressure-enabled stylus/tablet as input device.
Last modified: 2014-06-23 09:06:46 UTC
I'm using Gimp with a pressure enabled Wacom stylus/tablet as the main input device. When I open dialogs in Gimp, oftentimes they are unresponsive. Clicks (a swift tapping of the stylus on the tablet) on various GUI elements of those dialogs have no effect. This problem occurs with all opened dialogs in Gimp but are most prevalent in dialogs like 'open', 'save' and 'preferences' since these are used the most. There are several observations I have made that may point developers to the cause of this bug: 1) It only occurs when I am using the stylus/tablet with pressure enabled. 2) It only occurs when 'single-windows mode' is disabled. 3) It only occurs when the clicking-action has been performed by means of a swift tapping of the stylus to the tablet. Using the click-button on the stylus itself does not produce this bug 4) When an opened dialog is in an unresponsive state, normal behavior can be restored by moving the pointer outside of the dialog and hovering it over any position of the main GIMP window. 5) If, Immediately after clicking to open a dialog from he menu, the stylus is being pressed continually until the dialog has opened, the bug does not occur. This bug has previously been reported for Gimp 2.6 in 2010 (see: https://bugzilla.gnome.org/show_bug.cgi?id=635644) but still exists in Gimp 2.8. Since many users of graphical applications use pressure enabled stylus/tablet input devices, it is likely that many potential users of Gimp are affected by this bug. The only remedy at this moment is to use Gimp in 'single-windows mode' only or apply one of the 'quick fixes' mentioned in above points 4) and 5). Hope this helps! Gimp version: 2.8.8 (installed using PPA: ppa:otto-kesselgulasch/gimp) OS: Xubuntu, 12.04 amd64 Stylus/tablet device: Wacom Intuos4 $ gimp --version --verbose: GNU Image Manipulation Program version 2.8.8 git-describe: GIMP_2_8_6-115-g76dd14f GEGL version 0.2.1 is used (compiled with version 0.2.1) GLib version 2.32.4 is used (compiled with version 2.32.4) GdkPixbuf version 2.26.1 is used (compiled with version 2.26.1) GTK+ version 2.24.10 is used (compiled with version 2.24.10) Pango version 1.30.0 is used (compiled with version 1.30.0) Fontconfig version 2.8.0 is used (compiled with version 2.8.0) Cairo version 1.10.2 is used (compiled with version 1.10.2)
I have noticed a problem with mostly the same symptoms when using an Aiptek tablet on the current Debian Linux testing branch. It's even a bit more severe... if I open up a File dialog using (wired) PS-2 trackpad/mouse, or by entering an accelerator key, all of the input devices are mostly non-functional in the resulting dialog. The cursor tracks but clicking doesn't work. I independently rediscovered workaround #4... clicking on the desktop outside of any of the GIMP windows will usually (always?) restore the ability to click on items in the dialog window successfully. Based on looking at some earlier bugs related to GIMP and tablets, my hunch is that GIMP is losing track of when it should discard "core pointer" input events (on the assumption that a pressure-related event resulting from the same action will soon arrive). My guess is that it's appropriate to discard core-pointer clicks when the cursor is over a drawing area, and not appropriate in other circumstances. GIMP may not be switching between "discard clicks" and "process clicks" mode when a dialog window suddenly appears "in front of" the current window's drawing area. There's something about the act of clicking outside the window and then back in which seems to reset the "eat core pointer clicks" state. Possibly the explicit re-selection of the window, by the click-back-inside, does this, in a way which the automatic selection of the dialog window (on its first appearance) does not?
Does this happen for other GTK+-based applications, for example Inkscape, as well?
Thanks for the bug report. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find. *** This bug has been marked as a duplicate of bug 635644 ***