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 635644 - Some dialogs inactives when called by Wacom Stylus
Some dialogs inactives when called by Wacom Stylus
Status: RESOLVED OBSOLETE
Product: GIMP
Classification: Other
Component: User Interface
2.8.8
Other Linux
: Normal normal
: 3.0
Assigned To: GIMP Bugs
GIMP Bugs
: 657191 677125 723186 732584 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2010-11-23 21:29 UTC by Kukunin
Modified: 2018-05-24 12:54 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Kukunin 2010-11-23 21:29:22 UTC
I'm using Wacom Bamboo Touch&Pad CH460 in Ubuntu Lucid. I have latest kernel module from linuxwacom project ( 0.8.8-10 ). 
xsetwacom list says:

Wacom BambooFun 2FG 4x5 Pen eraser ERASER    
Wacom BambooFun 2FG 4x5 Pen stylus STYLUS    
Wacom BambooFun 2FG 4x5 Finger pad PAD       
Wacom BambooFun 2FG 4x5 Finger touch TOUCH  

My kernel: 2.6.32-26-generic

All of them I configured in GIMP input devices as Screen ( Disabled, Screen and Window select box ). It works good in GIMP, brush's dynamics affects to stylus pressure. But I have problem with some dialogs. If I call dialog from menu with stylus, its inactive. It ignore stylus clicks, mouse clicks and touchpad clicks. But elements changed if I hover it. If I call dialog through mouse ( touchpad ) or hotkey - it work well. I have problem with Open dialog, Save As and Configuration. For example, filter dialogs works well.

If I disable stylus device in Input devices ( Settings ), Dialogs works well, but I pressure of stylus doesn't work. If stylus device configured to Screen or Window - some dialogs doesn't work. 

Say me, if you need some extra info
Comment 1 David Gowers 2010-11-24 01:24:01 UTC
I confirm this -- and I can't drag out guides or sample points from the ruler. Also FWIW the same thing happens in MyPaint for the custom color selectors (eg. ring)

Arch Linux / Linux 2.6.35/ Wacom Graphire3
Comment 2 Martin Nordholts 2011-08-24 04:32:44 UTC
*** Bug 657191 has been marked as a duplicate of this bug. ***
Comment 3 Martin Nordholts 2011-08-24 04:34:09 UTC
Someone needs to figure out a way to reproduce the problem reliably, otherwise the chances for a fix happening is very slim. This is a bug we really should fix though.
Comment 4 Chris Mohler 2011-08-24 15:11:13 UTC
1. Create new image (either via menu or shortcut), accept defaults.
2. File->Save As via menu, using stylus.

Most of the dialog buttons are disabled.  If step #2 is performed via keyboard shortcut, then the dialog functions normally.

This is in 2.6.10 - the ubuntu 10.10 package, under gnome.  If I get some time I may be able to set up a build of current git - perhaps this weekend.
Comment 5 Chris Mohler 2011-08-24 15:19:03 UTC
Also - this is an Intuos 3.

I just discovered something else: when the dialog buttons are "stuck", you can use the stylus to return focus the the image window - then the buttons become active again.
Comment 6 Michael Natterer 2012-01-08 20:58:32 UTC
Please try GIMP 2.7.4 and report back, we won't fix 2.6 bugs any longer.
Comment 7 Akhil Laddha 2012-02-23 07:15:21 UTC
Could you please try to reproduce problem with GIMP 2.7.4 or later version and update the bug report with your findings, tia.
Comment 8 Alexia Death 2012-03-11 11:12:00 UTC
Rulers are now operational. Save dialog on and off isn't. I have tried to debug it in gimp, but it appears to be inherently a GTK bug. Nothing we can do about it in GTK2 and there is high probability that migration to GTK3 fixes it. Moving it to 3.0 milestone.
Comment 9 thiagopetruccelli 2012-08-06 03:48:56 UTC
Same here... I can't acces the text dialog that appear on canvas when you click to put in the text, with my wacom bamboo. I am using Ubuntu 12.04, gimp 2.8 from the launchpad ppa. 

To reproduce it, using the wacom bamboo, create a new file, click the text tool, click somewhere on the canvas, type something. Try to increase or decrease the size of the font; here in my computer it creates another text.
Comment 10 Vince C. 2012-11-12 13:25:33 UTC
Coming from bug #677125. I don't remember having this particular issue other than with Gimp as I am certain I happened to manage my Xfce desktop with the pen & stylus while using the tablet. Ok, it's not as convenient as the mouse but I don't remember other GTK dialog boxes being stuck at all so IMHO Gimp might very well be «able» to cure that particular issue. I might try again and report here later.
Comment 11 Michael Natterer 2012-11-12 13:48:28 UTC
*** Bug 677125 has been marked as a duplicate of this bug. ***
Comment 12 Vince C. 2012-11-16 15:28:49 UTC
(In reply to comment #10)
> Coming from bug #677125. I don't remember having this particular issue other
> than with Gimp as I am certain I happened to manage my Xfce desktop with the
> pen & stylus while using the tablet. Ok, it's not as convenient as the mouse
> but I don't remember other GTK dialog boxes being stuck at all so IMHO Gimp
> might very well be «able» to cure that particular issue. I might try again and
> report here later.

I've double checked. Handling my GTK2-based Xfce desktop doesn't exhibit that bug at all. Clicking menus with the stylus keeps dialogues and buttons and stuff active, everything clickable remains clickable. So I shall deduce this issue has been brought from within Gimp itself, not necessarily by GTK2. Just my short-sighted analysis. I'll do one more check with multi-document applications such as [Open|Libre]Office for it might be due to combining multiple windows in one single application. Just a guess though.
Comment 13 Michael Natterer 2012-11-16 17:34:11 UTC
If it doesn't happen on Xfce, than it's rather a bug on non-Xfce
desktops. GIMP doesn't combine windows in a single window.
Comment 14 Vince C. 2012-11-16 19:03:15 UTC
(In reply to comment #13)
> If it doesn't happen on Xfce, than it's rather a bug on non-Xfce
> desktops.

Well, I haven't been able to reproduce this issue at will in 2.8 either... Murphy's law probably.


> GIMP doesn't combine windows in a single window.

Hmmm, that was just a guess I made. Thanks for the clarification though.
Comment 15 Michael Natterer 2012-11-16 19:24:37 UTC
Thanks Vince for checking. Alexia, do you really still see this issue?
Comment 16 pjotter 2012-12-10 23:43:19 UTC
I can confirm this bug. I use Gimp 2.8 in Xubuntu 12.04 (amd64) with an Intuos 4 Wacom Tablet. I configured all Wacom related input devices to 'screen'. When I open a dialog like 'save as' or 'preferences', a lot of times the dialog stops responding to any Wacom-clicks. I can then either a) unplug the wacom and replug it, or b) I can move the mouse pointer outside of the dialog and hover it over the underlying drawing window and then return to the dialog again. This seems to 'fix' this strange behaviour.

I hope this information is helpful.
Comment 17 Vince C. 2013-03-08 13:08:53 UTC
Hi again peeps. It's always when you think it's gone that it shows its ugly face again, Murphy, of course.

I've been using my tablets for a while (Cintiq and Bamboo Fun) and I *sighs* experience this bug all the time again but with a variant. The problem occurred while I had Gimp (but also MyPaint) in full screen view. Whether I bring up dialog boxes on screen with mouse, keyboard or stylus, most of the time now they flee behind the main window as soon as I click them, try to reach a button with the mouse or stylus, in short: try to use them. I must bring the dialog box back to the foreground with alt+tab, switching to another app' then back. But the problem remains however: closing the dialog and bringing it once again doesn't even cure the issue.

Also I casually see the dialog window swapped behind the main window and go back by itself in the foreground... then off, then back and so on... until I close the window. This happens for instance when I try to resize the dialog. Or when I want to click a button and wait long enough to see the window come and go... Like I wanted to "Colourize", pressed "Apply" then wondered why no change was made, I clicked again, saw the box, clicked "Ok", nothing changed... Took me a couple of times until I realized the box was behind Gimp. But then a couple of alt+tab got rid of the issue. Most of the time I can say.

Also, the more powerful the machine the less slow the process: on my Core 2 duo laptop it can take up to 5 or 10 seconds to cycle between *poof* "not there" *poof* "there again" while on my Core i3 it only takes 2 to 3 seconds.

I suppose this is a GTK bug, right? How do we get rid of it as it is really, totally a pain in the neck to use (so far) whatever has dockable windows docked :-( .

Tell me if you need more information, package versions, whatnot.
Comment 18 Michael Schumacher 2014-06-23 09:06:46 UTC
*** Bug 723186 has been marked as a duplicate of this bug. ***
Comment 19 Michael Schumacher 2014-06-23 09:11:14 UTC
Changing version as indicated in bug 723186. It probably still happens in 2.8.10.
Comment 20 Dave Platt 2014-06-24 00:17:15 UTC
I can confirm that it does happen in 2.8.10, on my laptop running Debian's "testing" distribution (current build there is 2.8.10-1), under xfce4.

To summarize (and add to) what I reported in 723186 (just closed as a duplicate):

-  It does not occur if GIMP is operating in "single window" mode.

-  It occurs almost 100% of the time if I use GIMP in "multiple windows" mode.

-  It affects operations with an ApiTek Hyperpen 8000 USB.  I just got an Intuos 3, expect that it'll occur there as well, but haven't personally confirmed this.

-  The problem seems to occur under the following conditions:  the tablet stylus is in use and the focus is on the main document window.  I hit a key, or click on something to bring up a dialog window.  The dialog appears in front of the main document window (as it should).  In this window, clicking on buttons with the stylus either has no effect, or the buttons highlight but don't activate when released.

-  The problem can often be cured by selecting a window not belonging to GIMP, and then clicking back in the dialog window.

My inference is roughly as follows.  The affected sub-device are all defined (in Xorg.conf) with the "send core events" disabled (as seems to be required in order to have pressure sensitivity, tilt, etc. work correctly).  When GIMP "sees" a dialog window activated by a click, it seems to be smart enough to put this window into a mode which will accept the non-core input events and "do the right thing".  On the other hand, if a GIMP dialog window pops up in the front (and grabs focus this way), this "accept non-core events" setup doesn't happen, and the stylus-click input events are dropped on the floor when they occur.

I could well be wrong, but it feels to me as if something along these lines is what's taking place.  There's something in GIMP's handling/setup of dialog windows, which (under certain circumstances) fails to condition the window to handle non-core input events.
Comment 21 Vince C. 2014-06-24 07:14:27 UTC
(In reply to comment #20)
> I can confirm that it does happen in 2.8.10, on my laptop running Debian's
> "testing" distribution (current build there is 2.8.10-1), under xfce4.
...
> -  The problem can often be cured by selecting a window not belonging to GIMP,
> and then clicking back in the dialog window.

I can somewhat add to what Dave said although it is a little different, just the cure is the same.

Under GTK2, full-screen windows that pop up dialog boxes suffer from a focus/activation flapping when "hover to activate" is enabled. The problem occurs when I set mouse properties so as to automatically focus the window under the pointer instead of having to click. In such conditions when an application window is set to full screen and a dialog box that belongs to the application appears, if I hover the mouse out of the dialog box, the dialog box starts flapping between the foreground and behind the main window. How fast flapping occurs depends on I-don't-know-what. On my laptop the period is about 1 second and I have seen it happen faster.

Clicking anywhere on the main window brings back the dialog box, sometimes with the button or item pressed if it happens to be under the pointer. I experience this with any application but mostly Geany and Gimp, which are the only ones I set to full screen and that have dialog boxes I use that often. During that "flapping" the dialog remains unusable.
Comment 22 Robert Susmilch 2014-07-02 15:44:57 UTC
*** Bug 732584 has been marked as a duplicate of this bug. ***
Comment 23 Robert Susmilch 2014-07-02 15:46:58 UTC
Coming from bug #732584:

Just rebuilt GIMP git, and bug presists. 

Using a Wacom CTH-480 on Fedora 20 x64.

Clicking open file brings up the open file dialog which doesn't respond to
tablet inputs or mouse inputs. You can follow the mouse around and the buttons
like Open and Cancel become highlighted and "gain focus" but are unresponsive.
I have to use the keyboard to navigate to my files which works as expected.

This also happens in other dialogs such as preferences for both tablet and
mouse. HOWEVER if I drag the mouse or tablet pointer off the edge of the
dialog, then back on something resets and it works normally with tablet and
mouse on the dialog.

Does not happen all the time on dialogs, but ALWAYS on open file.

----------------------------------------------------------------

Confirmed keyboard shortcut for open file allows me to use stylus to navigate as expected.
Comment 24 GNOME Infrastructure Team 2018-05-24 12:54:31 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gimp/issues/350.