GNOME Bugzilla – Bug 457288
Rectangular tool stuck in subtraction mode
Last modified: 2018-05-24 12:13:11 UTC
The rectangular selection tool is stuck in subtraction mode - This means that if I try to select something outright, it doesn't. The obvious 'fix' is to just hold down shift, but that causes it to select a perfectly square area. I've had the bug since 2.2.13, and when I upgraded, it is still stuck. Are there any components used from version to version? No other tools are stuck, or have become stuck. If this is not a bug, and an OS problem, feel free to remove this. I'd just like to know... if possible. Windows XP, service pack 2 + all automatic updates since then.
Did you try to set a different mode in the tool options?
(In reply to comment #1) > Did you try to set a different mode in the tool options? > Yes. It is still stuck. I can use the tool mostly well if I use shift + fixed size. But that requires guessing the size of the area I want, sometimes.
I can't reproduce this. The mode is saved to whatever value was active when I quit GIMP, but setting it to a different one in the tool options is possible (and gets saved, too).
(In reply to comment #3) > I can't reproduce this. The mode is saved to whatever value was active when I > quit GIMP, but setting it to a different one in the tool options is possible > (and gets saved, too). > Well, alright. Thanks. I can't get it unstuck, so I guess I'll have to live with it. I don't know what caused it to get stuck, and it's not a keyboard issue (it's only the GIMP) so I can't provide further info. And I have been able to save the mode, fixed vs free etc., but that doesn't change anything. It still starts up in subtraction mode. Even if I close the GIMP with a different tool open. You can mark this as closed if you wish. I'm saving it as not-a-bug.
Are we talking about the same "Mode"? See http://docs.gimp.org/en/gimp-tools-selection.html#gimp-tool-select However, Bugzilla is not a help forum, so next time you should ask on the mailing lists after consulting the manual.
This is trivial to reproduce: 1. Open an image or create a new one. 2. Select the rectangle tool. 3. In the tool options, select "replace the current selection" (the first option - this should be the default) 4. Press and release Ctrl in the image window. The tool is now stuck in subtraction mode. This doesn't happen if you press and release Shift instead of Ctrl in (4). If you use Shift, the cursor gets the "+" indicator while Shift is pressed, and goes back to normal when Shift is released. Ctrl gets stuck, however.
I agree with the previous status of NOTABUG, RESOLVED and CLOSED. Reasoning: I was hasty to post, and I didn't know GIMP as well as I thought I did. This "bug" I submitted was resolved by pressing one of the specially designed mode buttons. This fixed the issue of it always starting up in subtraction mode. There is no bug, only my stupidity. Please close this thread.
> was resolved by pressing one of the specially designed mode buttons This is not a fix; it's a workaround :) I just found out that gimp_display_shell_canvas_tool_events() does *not* get called when you release Ctrl. It gets called just fine when you press/release Shift and when you press Ctrl. I'll dig deeper into GTK+ to see if it's eating the Ctrl-release...
Actually, gimp_display_shell_canvas_tool_events() gets called just fine when you release Ctrl. However, event->keyval = GDK_ISO_Prev_Group (0xfe0a) instead of GDK_Control_L or GDK_Control_R. That's why the function is ignoring the Ctrl release. (When you press Ctrl, event->keyval = GDK_Control_L as expected.) GTK+ does some magic to deal with this kind of stuff relative to the X keyboard map; I'll look it up.
I'm still unable to reproduce this.
I'm getting GDK_ISO_Prev_Group because I've got "both Ctrl keys change keyboard layout" turned on in gnome-keyboard-properties. If I disable that option, pressing and releasing Ctrl in the GIMP no longer causes it to get stuck in subtract mode. This is still a bug somewhere. (01:12:47 PM) owen: federico: OK, svu might have an idea of whether there would be an alternate way to do that with XKB that avoids the issue (01:13:34 PM) owen: federico: But it's certainly what is giving the issue (01:14:35 PM) owen: federico: it's all possible that the case of a self-modifying key should be special-cased to give consistent values on press and release (01:14:59 PM) owen: federico: I don't really know enough about XKB to know how feasible that would be to implement or whether it would be consistent with the spec
This is very similar to the general bug #346029 - which is https://bugs.freedesktop.org/show_bug.cgi?id=7430 upstream.
This is relevant for Windows?
(In reply to comment #13) > This is relevant for Windows? > Probably not. Moving to Linux.
Unfortunately, there is absolutely nothing that GIMP can do about it because it does not get the event that it should normally get from the X server through GTK+. This bug can only be solved on the XKB side, so I am marking this as a duplicate of bug #346029 (like the previous bug #345726 that also affected GIMP). *** This bug has been marked as a duplicate of 346029 ***
I forgot to mention that the easiest workaround for those who are affected by this bug is to disable the keyboard layout switching: in GNOME, this is in System -> Preferences -> Keyboard -> Layout Options -> Layout switching Deselect the option "Both Ctrl keys together change layout", or "Both Alt keys..." or "Both Shift keys...". A better solution is to use the Keyboard Indicator applet.
The problem with closing a bug which you can't solve (but someone else can) is that the bug will be forgotten, and there will be no incentive to fix it :) Reopening.
There's action in the upstream bug, so we can be confident that it will be fixed soon. Just leave it around; I'll close the bug once the XKB fix comes in.
Well, you could have reopened bug #345726 instead, but that will do for now ;-)
Federico, has anything happened related to this in the meantime? It doesn't seem to make much sense to keep a bug report open for a bug in xkeyboard-config that is stalled.
No idea. CCing svu. Sergey, do you know the status of this bug upstream? Do you need me to test anything?
Federico, and news about this bug?
No idea, sorry. I think svu mentioned at some point that this would be a huge pain in the ass to fix with XKB rules. (In the meantime, many months ago, I switched to using Shift-Shift instead of Ctrl-Ctrl to switch keyboard layouts. Now the bug happens with Shift instead of Control, and the tool gets stuck in addition mode - not as bad, but still...)
So you traded one evil for another :) I really don't know what to do here, the press and release events are not paired, and there is no focus in our out to compensate for the missing ones. I'm out of ideas.
Well, I changed from ctrl-ctrl to shift-shift for ergonomics, not to actually deal with this bug :) Assuming that comment #9 still matches the code, would it be possible to hack gimp_display_shell_canvas_tool_events() so that it checks the event's state and uses that to frob the mode of the selection tool? Something like static gboolean gimp_display_shell_canvas_tool_events (...) { if (selecting && event->type == GDK_KEY_RELEASE) { if ((event->state & GDK_CONTROL_MASK) == 0) stop_subtracting (); ... } else { /* process keys normally */ ... } } i.e. "we know key_release keysyms may not be accurate, but we can use the event's state to figure things out" just for the selection case.
Are there any objections if I close this as WONTFIX? We can't compensate for all possible things that modify the event stream, and windows users are told all the time to go away with their "gui tweaking" tools.
Or maybe I should get off my ass and see if this easily fixable with a hack like the one I mentioned :) Feel free to make this bug really low priority.
Actually, I'll WONTFIX it, and reopen it if I ever produce a working patch.
Thanks :)
Created attachment 204988 [details] [review] gimp-bgo457288.diff This patch doesn't work, but it's probably a start. The modes don't "return" to what they were before toggling, I get a g_warning() sometimes when refocusing a window, and it's just not done - but make of it whatever you want :)
Try dropping the last "active" from the function name. Reopening so it doesn't get lost.
I regularly get this on Mac OS X 10.8.5, with GIMP 2.8.6. Happens when the selection tool is active (rectangular, but also seen it happen with elliptical selection), then using Cmd + Tab to switch between applications. Eventually, GIMP gets the selection tool stuck in subtraction mode, with no possible recovery, apart from quitting and reopening GIMP.
-- 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/246.