GNOME Bugzilla – Bug 771736
Stylus Pen is Losing the Focus when we use the File > Save and Export menus with MWM and desktop partially visible.
Last modified: 2018-05-24 16:56:50 UTC
When we have Stylus Pen enabled on GIMP Git Master... in certain cases the stylus pen loses the focus with dialogs of File menu, mainly the Save and Export menus. --- ENVIROMENT AND SETUP OF DEVICES GIMP Git Master Commit be91db8 Ubuntu GNOME 14.04.2 | DE GNOME 3.10 # GIMP in MWM session # GIMP Configure Input Device - Core Pointer enabled > Screen - Graphic Tablet enabled > Screen - USB Optical Mouse > Disabled - Virtual core XTEST pointer > Disabled --- STEPS 1) Open GIMP Git Master via terminal; 2) Open Device Status dialog; <GIMP without document show always selected only Core Pointer, if you grip the mouse or the stylus, in the Device Status dialog is always enabled only the Core Pointer> 3) Pick up the pen stylus and create a new document; <Now the Device Status Dialog show selected the stylus pen> 4) Paint something on canvas using the pen stylus, after File > Save, in this step the dialog is normally focused, click cancel; 6) Make recursively the 4th step until when the File > Save is not focused. In certain conditions the issue appears in the first cycles, 2nd or 3rd cycle... other times, must be patient ;-) The order of steps seems important... sometimes, until to understand the cycle of the bug is better quit GIMP and again return to 1st step.
On my system (gentoo linux), making a new document using the stylus (step 3), then painting using the stylus (step 4), then selecting File/Save (step 5?), it's impossible to save the document or to cancel saving the document (the cancel and save buttons don't work). This happens immediately, no need to make several tries to trigger this issue. Putting down the stylus while the File/Save dialog is still open, and trying to click Save or Cancel with the mouse, still no response. The only option is to close the Save dialog using the X in the upper right corner of the Save dialog window (works with mouse or stylus). And then try again using the mouse. When putting down the mouse and picking the stylus back up, the stylus-associated brush and color is correct, but the brush size has reverted to the default brush size.
A work-around here is to move the stylus/mouse pointer on the canvas before clicking the save/cancel button. Another one in my settings is not to disable the optical mouse.
(In reply to Massimo from comment #2) > A work-around here is to move the stylus/mouse pointer on the > canvas before clicking the save/cancel button. Normally, when the focus is lost, I am moving the stylus pointer on the desktop and pick on. This tip is working. > Another one in my settings is not to disable the optical > mouse. I have excluded the device because I would understand the issue in minimalist way. Effectively, this setup is sufficient to use the mouse and stylus... and it seems that is more safe... I am not a specialist, but the Core Pointer can be used with different devices, in fact, my optical mouse is plugged and I can use as Core Pointer.
I have made a fast test and perhaps this could help understand where is origin issue: 1) MWM with a small document with desktop visible yet; 2) Open a document and paint something on; 3) Move the stylus pen outside of window canvas (over desktop, but without crossing any other GIMP dialog) and return again to the window and select File menu > Save; 4) All times the focus is lost and is necessary a touch of the stylus over the canvas or on desktop to return the focus in the Save dialog.
(In reply to jose americo gobbo from comment #4) > 3) Move the stylus pen outside of window canvas (over desktop, but without > crossing any other GIMP dialog) and return again to the window and select > File menu > Save; The pointer must to cross the canvas and to touch on desktop to recover the focus on Save dialog.
(In reply to jose americo gobbo from comment #4) > I have made a fast test and perhaps this could help understand where is > origin issue: > the origin of the problem I'm seeing is this call: https://git.gnome.org/browse/gimp/tree/app/widgets/gimpsavedialog.c#n316 probably because it is setting the busy cursor to update the view with the folder content > 1) MWM with a small document with desktop visible yet; > 2) Open a document and paint something on; > 3) Move the stylus pen outside of window canvas (over desktop, but without > crossing any other GIMP dialog) and return again to the window and select > File menu > Save; > 4) All times the focus is lost and is necessary a touch of the stylus over > the canvas or on desktop to return the focus in the Save dialog. I don't need to touch the canvas to be able to click the cancel button with the pen, just hover the canvas. The focus is usually related to the keyboard and IIRC that seems to work.
(In reply to Massimo from comment #6) > > I don't need to touch the canvas to be able to click the > cancel button with the pen, just hover the canvas. > > The focus is usually related to the keyboard and IIRC that > seems to work. I confirm this, on GIMP Git master commit e909b77.
Created attachment 336194 [details] [review] Unsafe dirty hack To reproduce this bug it is not necessary to plug in the tablet it is enough to enable the laptop touchpad as input device, although any enabled input device is good as well. The problem seems to happen when a dialog opens above the menu above the canvas with the pointer already above the area to be occupied by the dialog. It is possible to use the keyboard to open the dialog (the menu mnemonics, not the action shortcut <Alt>-F S not <Ctrl>-S) It is not exactly repeatable, for example changing the default folder of the Save dialog made it repeatably happen/not happen. It seems that depending on the sequence dialog exposure menu hiding there is a case where a pair of crossing events is not synthesized and the display object ends up having a ignore_core_events flag set which cause the ignorance of pointer related events until the pointer is moved over the canvas. One bad way to force clearing that flag is to hide and show the dialog during the map-event notification, another is to directly clear the flag, perhaps there is something sane I'm not thinking about.
From curiosity, is this the type of bug that will disappear with gtk3?
I hope so :)
Confirming per comment 6 ff. I guess it could also be cross-platform? Does this also happen in 2.8?
(In reply to Michael Schumacher from comment #11) > Confirming per comment 6 ff. I guess it could also be cross-platform? Does > this also happen in 2.8? It happens in 2.8 and it happens (non repeatable) also with other dialogs: Image->Scale Image if the menu opens behind the dialog (it depends on the window size, menu translations etc.) this just to explain that the fix in gimpfiledialog.c is not enough and a map_event member function added to gimpdialog.c is not always called... Regarding the cross-platform, there are many reports from Windows that are attributed to Skype or anti-viruses, they should be investigated to see whether input devices are enabled and moving the pointer over the canvas restores buttons clickability. IIRC I did not reproduce it on my Windows 64, but tested only few times
I think this one was already reported in bug #635644
Comment on attachment 336194 [details] [review] Unsafe dirty hack By comment 8.
On GIMP 2.10 rc1 this issue is yet present.
Setting a 2.10 milestone since there is a first hack proposal and good study of the problem. So it should make finding the right solution easier. It won't be a priority for 2.10 but for a 2.10.x likely. :-)
-- 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/970.