GNOME Bugzilla – Bug 163163
GIMP switches from stylus to core pointer after saving (Wintab initalization in a noninteractive child process stops tablet input, lazy wintab init)
Last modified: 2005-03-05 21:08:25 UTC
When using the Win32 version of GIMP 2.2.1 with GTK version 2.4.14 and a Wacom graphics tablet, executing a menu command causes the tools to lose their settings and revert back to GIMP's startup defaults. For example: I set my stylus to use the Brush tool, change the brush size to Fuzzy size 3, set pressure options, and change the color to blue. After I save my work via File>Save, the Brush tool's options revert back to the default size, no pressure sensitivity, and black. Things I have tried: - I have tried starting GIMP both with no startup switches (the default) and with the --use-wintab switch, - I usually save my work as PNGs, so I tried saving in various formats, - I usually save my work to a mapped SMB share, so I also tried saving to the local disk, - I have tried closing other applications that use GTK, such as GAIM, to eliminate the possibility of interference. How to reproduce: 1. Create or open an image, 2. Set tool options including brush size, color, and pressure options, 3. Use a menu command (the ones I can confirm are File>Save and File>Revert) I can also confirm that this bug existed in the previous version of GIMP, 2.2.0.
Some of the settings such as the brush and the foreground / background color are device dependant. If you switch to the mouse, the settings for the mouse device become active. If you switch back to the stylus, the settings from the stylus become active again. Please open the Devices dialog and verify this behaviour.
I am aware that the settings are device-dependent, and when I discovered the bug I was only using one device: my stylus tip. I do verify through Devices that the settings change when I change the device (eg. flipping the stylus over to use the eraser). Curiously enough, this bug seems to reproduce sporadically; sometimes the tools continue to work as they were set, other times the tool will lose its settings.
As a testament to this bug's sporadic behavior, I have also witnessed the following: I set up my stylus as follows: I set the tip device to the Brush tool, and I set the eraser device to the Eraser tool. After a File>Save or File>Revert, sometimes it will produce the behavior I noted in my initial report. Other times, the tools will change completely for both devices (both devices will revert to the Rectangular Selection tool, GIMP's startup default).
I am not aware of any code in GIMP that could be causing this behaviour but since you claim the problem exists, I will have to reopen this bug report.
Then perhaps this is less of a problem with GIMP itself and more of a GIMP/wintab interaction problem. I have only observed this problem when working with a graphics tablet; PS/2 mouse devices seem to work fine. I also use the Linux version of GIMP 2.2.1 with the same tablet and haven't had such problems.
That's very likely. Just that is there is no GIMP/wintab interaction at all. Your problem would be a GTK+ problem then since that's where the wintab integration takes place. GIMP just sees events coming from GTK+/GDK. This bug should probably be reassigned to GTK+. But then, I doubt that someone from the GTK+ team would find the time to look at it.
It seldom hurts to ask... I tried to reproduce this, and what happens for me is that when save is activated, GTK+ gets a tablet proximity out message and then no more tablet messages and instead just ordinary mouse messages, which get translated into core pointer events. This produces more or less the problem that Michael describes because GIMP switches to the Core Pointer device and so the color, brush etc changes. Michael, can you confirm this by having the Devices dialog open when saving and checking if the little black arrow stays in front of the core pointer device after saving when using the stylus? To get the tablet to work again, it is sufficient for me to switch focus to some other application and then back to GIMP. For me the problem occurs when saving to PNG, JPG and TIFF but not XCF (probably because that is built-in). It only occurs when the saving does not bring up a dialog and does not occur when reverting. The problem also does not occur when for example repeating a gaussian blur. Are there any differences in how the file plugins are invoked compared to the gaussian blur plugin? I might try to debug and if possible fix this in a few weeks unless somebody else has already taken care of it.
I can confirm this behavior. After executing a few saves, the device changed from stylus to core pointer. I can also confirm that taking focus from GIMP and then going back restores the stylus as the active device. I saved using all the common Web formats yesterday and managed to reproduce this bug. I have just now tried XCF and you're right again - the bug doesn't seem to reproduce when using the GIMP native format (at least, not during the times I've tried it).
OK, I've finally done some more testing. With current GTK+, Wintab is initialized as soon as gtk_init is called, including in the GIMP plugins that call gtk_init through gimp_ui_init. The tablet driver seems to get confused if Wintab is initialized but no window is shown before the process exits. And the reason the problem occurs for the file plugins but not the gaussian blur is that the latter doesn't call gimp_ui_init if it doesn't bring up a dialog but the file plugins do. I tried changing GTK+ so that it only initialized Wintab in the main GIMP process, and then no problems occured when saving. I think the best way to fix the problem is to implement lazy wintab initialization as Owen suggested in bug #162334. Reassigning to GTK+ (originally reported against GIMP 2.2.1).
*** Bug 163190 has been marked as a duplicate of this bug. ***
It doesn't seem to be that hard to implement lazy wintab initialization. I'll attach a proof of concept patch for the GTK+ sources that seems to work.
Created attachment 36779 [details] [review] Patch to implement lazy wintab initialization on win32 Here's the patch, against gtk-2-6 sources from anoncvs. Tests performed: testinput --gdk-debug=input (wintab initialized - good) testgtk --gdk-debug=input (wintab not initalized - good) gimp-2-2 (wintab working and saving does not switch to the core pointer - good) I think the work that may be left to do is code cleanup and perhaps some more testing. Comments and suggestions are welcome :)
Patch applied to HEAD and gtk-2-6. Thanks!
*** Bug 162803 has been marked as a duplicate of this bug. ***
*** Bug 162334 has been marked as a duplicate of this bug. ***