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 601261 - Keyboard shortcuts ocasionally stop working
Keyboard shortcuts ocasionally stop working
Status: RESOLVED DUPLICATE of bug 136280
Product: GIMP
Classification: Other
Component: General
2.7.4
Other Windows
: Normal normal
: ---
Assigned To: GIMP Bugs
GIMP Bugs
: 686721 689120 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2009-11-09 14:26 UTC by Konstantin Beliakov
Modified: 2012-12-04 21:13 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Konstantin Beliakov 2009-11-09 14:26:01 UTC
I have two input languages installed in my Windows Vista Enterprise SP1 - English (US) and Russian (RU). If I set Ctrl-Shift key sequence for switching between input languages, I ocassionally face a problem that GIMP's keyboard shortcuts stop working. Nothing happens when I press Ctrl-Z, Strl-S, etc., while I still have an ability to undo or save a file via GIMP's menus. It should be noted that this bug never appears immediatelly after GIMP was launched. It may happen only after some period of intensive working with images. To return normal shortcuts operation, I have to restart GIMP. If I change key sequence for switching between input languages to Alt-Shift via Windows's language bar, keyboard shortcut trouble never appears and GIMP works normally. I've heard from people in my office who also use Vista and switch languages via Ctrl-Shift that they face the same problem.
I mark this bug as major because using Ctrl-Shift is long-term habbit for me and it's very hard to switch to another sequence. At the same time, bug described above makes working with a large amount of images very unconvenient.
But, I'd like to mention that I never had problems vith GIMP when running it in Lunux :)
Comment 1 Michael Schumacher 2009-11-09 15:16:27 UTC
This is probably a duplicate of bug #136280.
Comment 2 Konstantin Beliakov 2009-11-10 05:23:22 UTC
(In reply to comment #1)
> This is probably a duplicate of bug #136280.

I'm not sure that it's the same bug. The problem I described never appears when I switch layouts via another key sequence, not Ctrl-Shift. When I use Ctrl-Shift, it never appears after the first layout switching. Usually I have an ability to open, edit and save about a dozen of images before shortcuts stop working unexpectively. I think there is something like a conflict between GIMP's Ctrl-Shift-ANYKEY shortcuts and Windows's Ctrl-Shift layout switching.
Comment 3 Tor Lillqvist 2009-11-10 11:02:29 UTC
I agree with Konstantin, this is probabluy a case of the Ctrl+Shift that Windows by default uses (I think) to shift between keyboard layouts interfering. I too have several keyboard layouts switchable (for testing, not because I would actually know any of the corresponding languages like Greek, Chinese or Russian...). Each time I add a keyboard layout Windows insists on automatically assigning a key sequence to changing keyboard layout, and I always have to turn it off, that's a little irritating. But otherwise it interferes in an extremeley annoying way especially with Emacs... I guess it's the same with GIMP, I haven't noticed there as I in fact rarely use GIMP.

I guess that is what you have to do, too. Either don't assign any key sequence at all to the "Switch Input Language" and "Switch Keyboard Layout" functions in the "Text Services and Input Languages" dialog, or assign one of the other alternatives. Unfortunately there are just two alternatives to Ctrl+Shift (at least in my English Windows 7).

If that means you have to learn a new way to switch keyboard layout (by using the icon on the taskbar), it's a pity, but not really much one can do about it. It would be nice if there was a way to tell Windows that in some specific applications, the input language hot keys shouldn't be active.

To change all GIMP default shortcuts that involve Ctrl+Shift in the source code is not really an option, but you can customize them yourself as you like, of course. It involves placing a file called menurc in your personal GIMP settings directory (.gimp-2.6 in your profile directory). Check the ps-menurc example file.

Hmm, actually I wonder there is some Windows message that is sent to the app and asks whether it is OK to switch keyboard layout and/or input language. GTK+ could handle that, and if it is possible to differentiate whether the change is causes by a hot key or an explicit choice in the thingie in the taskbar, possibly reject it. There would then be some Windows-specific API to tell GTK+ to either reject or accept such changes. An app like GIMP where its own set of shortcuts is large would tell GTK+ to reject them.
Comment 4 Tor Lillqvist 2009-11-10 11:51:01 UTC
Yup, WM_INPUTLANGCHANGEREQUEST looks like it could be used to reject accidental input language change requests in an app. (Assuming it's OK for the app to decide, "in this app the user is not allowed to change input language with hotkeys as overlapping key combinations are used for this app's own shortcuts".) I think it should be possible to filter that in GIMP itself even and not have to wait for GTK+ to get the capability (although eventually it would be nicer to put this functionality in GTK+ of course). Will have a look.
Comment 5 Michael Schumacher 2009-11-10 12:11:23 UTC
We might want to allow input language changes whenever a text entry has the input focus, and disallow them otherwise.
Comment 6 Tor Lillqvist 2009-11-10 14:31:29 UTC
Hmm, that would make it quite a bit more complex, especially if we want it to be in GTK+, as the low-level message handling in gdk/win32 of course by itself doesn't know when focus is in a text entry and when it's somewhere else, so the calls to the hypothetic new gdk_win32_enable_input_language_shortcuts() functions would have to be here and there in gtk. If this functionality was in GTK+, then probably it should not be exposed to applications, because if it was, it would be harder for gtk to handle it. Or maybe gtk should just not touch it if the app has called the function?

But yeah, as such it does sound like the right thing to do.
Comment 7 Tor Lillqvist 2009-11-10 14:59:01 UTC
Unfortunately some initial testing indicates that no WM_INPUTLANGCHANGEREQUEST is posted after all, despite what MSDN claims. Sigh... I wonder if the code needs to specifically request that themessage is posted to its focus window using some API?
Comment 8 Michael Natterer 2012-01-08 04:48:00 UTC
Please try GIMP 2.7.4 and report back, we won't fix 2.6 bugs any longer.
Comment 9 Akhil Laddha 2012-02-22 10:59:23 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 10 Konstantin Beliakov 2012-02-22 13:56:36 UTC
I still can reproduce this bug in GIMP 2.7.5. Moreover, now I can provide you with exact steps to reproduce it in Windows 7 Enterprise:

1. Open the "Text Services and Input Languages" dialog (Control Panel > Region and Language > Keyboard and Languages > Change Keyboards).
2. Add "Russian (Russia)" input language.
3. Switch to English.
4. Start GIMP.
5. Switch to Russian.
6. Press Ctrl+N to create a new image (shortcuts still work at this step).
7. Click OK in the "Add new image dialog"
8. After an image is created, try to use any shortcut - they have no effect now.

Steps to return shortcuts to operation:

1. Switch back to English.
2. Close all opened images.

I think something goes wrong when an image is created at a moment when Russian is chosen. If English is chosen, I can create an image and then switch layouts and use shortcuts with no issue. Also, I see there is no matter what keyboard switch shortcut is used. Language can even be switched with a mouse, via the "Language bar".
Comment 11 Konstantin Mochalov 2012-04-17 08:24:43 UTC
Occurs in all GTK+ programs, for example Pidgin. Shortcuts sometimes stop to work after switching input method, even ctrl+c and ctrl+v shortcuts in text input fields.
Comment 12 Michael Schumacher 2012-05-28 10:51:38 UTC
I guess we should reassign this to GTK+.
Comment 13 Max Mustermann 2012-11-12 19:26:55 UTC
*** Bug 686721 has been marked as a duplicate of this bug. ***
Comment 14 Max Mustermann 2012-12-04 20:29:52 UTC
*** Bug 689120 has been marked as a duplicate of this bug. ***
Comment 15 Max Mustermann 2012-12-04 21:13:00 UTC
After consultation in IRC: This is obviously a duplicate of bug #136280.
The common pattern are non-working keyboard shortcuts in Non-Latin languages, like Russian, Gree, Hebrew, Hangual (2-set-Korean). Both Windows and Mac OS X are affected.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 136280 ***