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 136280 - Keyboard shortcuts with Latin letters don't work in Non-Latin keyboard layouts
Keyboard shortcuts with Latin letters don't work in Non-Latin keyboard layouts
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: .General
2.2.x
Other All
: Urgent major
: Small fix
Assigned To: gtk-bugs
gtk-bugs
: 322696 601261 689831 696134 745543 765401 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2004-03-05 13:51 UTC by Nickolay V. Shmyrev
Modified: 2017-01-30 16:40 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Various Non-Latin keyboard layouts (29.27 KB, image/png)
2012-12-07 13:35 UTC, Max Mustermann
Details

Description Nickolay V. Shmyrev 2004-03-05 13:51:52 UTC
There is problems with shortcuts in win32 port of gtk (in latest version)

To see it, run program with default layout EN:

#include <gtk/gtk.h>

gboolean key_cb (GObject *obj, GdkEventKey *key, gpointer data)
{
g_message ("keyval = %d, hardcode = %d, group = %d ", key->keyval,
key->hardware_keycode, key->group);
return FALSE;
}


#include <gtk/gtk.h>

int main( int   argc,
          char *argv[] )
{
    GtkWidget *window;
    GtkWidget *button;
    
    gtk_init (&argc, &argv);
    
    window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
    button = gtk_button_new_with_mnemonic ("_&#1060;&#1072;&#1081;&#1083;");
    gtk_container_add (GTK_CONTAINER(window), button);
    gtk_widget_show_all  (window);

    g_message("Keyval %d", 
	gtk_label_get_mnemonic_keyval(
	    GTK_LABEL(gtk_bin_get_child(GTK_BIN(button)))));    
    
    g_signal_connect (G_OBJECT(window), "key-press-event",
G_CALLBACK(key_cb), NULL);
    gtk_main ();
    
    return 0;
}

Here is label contains russian text in UTF8 with shourtcut on symbol U0424
consider starting it in with EN(english) windows layout. This shortcut
can't be used, because then it created, current windows layout is EN, so
there is no keycode on unicode symbol. Expected behavor (as in Linux) is
that shortcut work when you press Alt_A key in English layout or Alt +
U0424 in russian (it is one key, which in english keyboard is A).

 This is because you hold in keysyms table only keys for current layout,
not for all unicode keys. In russian keyboard there is no english letters,
so described behavior is default (EN layout by default, RU layout after
switch). Users should often switch their layout to type international commands.
Comment 1 Tor Lillqvist 2004-03-05 21:18:49 UTC
But if I run the program (once I changed the &# stuff into UTF-8) 
with a russian keyboard layout, pressing Alt+<cyrillic ef> works fine?

Do I understand corretly that you expect that, if this program is run 
with an English keyboard layout, GTK should look up what keyboard 
layout(s) the U+0424 character exists on, check what keycode it has, 
and accept also the corresponding physical key on the current 
(English) keyboard? Is this really what happens on Linux/XFree86? 
What if the character exists on several other keyboard layouts than 
the current one, and with different keycodes? This would be the case 
for instance if the current keyboard layout is Russian, and you run a 
program that has a mnemonic on Alt_Y. Y is on different keys in the 
German and English keyboards. Which one of these two keys should then 
be used?

How common is it that Russian Windows users switch back and forth 
between keyboard layouts?
Comment 2 Nickolay V. Shmyrev 2004-03-06 12:48:10 UTC
>Do I understand corretly that you expect that 
 
I completely agree with Owen: 
 
GTK+ does fuzzy-group matching for accelerators/mnemonics;  
if you have a ?/a key, as is common for Russian keyboards, if you  
have only a '?' or 'a' as a mnemonic, then that Alt-?/a will 
activate the mnemonic in either group. 
 
> Is this really what happens on Linux/XFree86?  
 
Yes, it is. Moreover, it is the default behaviour in Windows 
programs like MS Word. 
 
I think, appropriate solution will be if GTK will look through all 
layouts available for user (for example RU and EN) and expose this 
information in "group" field. If so, I can try to write a patch. 
 
 
Comment 3 Elijah Newren 2004-06-19 18:42:35 UTC
Mass changing gtk+ bugs with target milestone of 2.4.2 to target 2.4.4, as
Matthias said he was trying to do himself on IRC and was asking for help with. 
If you see this message, it means I was successful at fixing the borken-ness in
bugzilla :)  Sorry for the spam; just query on this message and delete all
emails you get with this message, since there will probably be a lot.
Comment 4 Tor Lillqvist 2004-08-07 23:59:35 UTC
What about my other two questions in Comment #1?
Comment 5 Nickolay V. Shmyrev 2004-08-09 18:25:13 UTC
>But if I run the program (once I changed the &# stuff into UTF-8) 
>with a russian keyboard layout, pressing Alt+<cyrillic ef> works fine?

Yes, it works.

>Do I understand corretly that you expect that, if this program is run 
with an English keyboard layout, GTK should look up what keyboard 
layout(s) the U+0424 character exists on, check what keycode it has, 
and accept also the corresponding physical key on the current 
(English) keyboard? Is this really what happens on Linux/XFree86? 
What if the character exists on several other keyboard layouts than 
the current one, and with different keycodes? This would be the case 
for instance if the current keyboard layout is Russian, and you run a 
program that has a mnemonic on Alt_Y. Y is on different keys in the 
German and English keyboards. Which one of these two keys should then 
be used?


It would be perfect if GTK will discover layouts that available to user and 
behave like the Unix version does. You can easily check such behavior by 
exporting RU locale :)

>How common is it that Russian Windows users switch back and forth 
>between keyboard layouts?
 
They switch very often

Comment 6 Max Mustermann 2012-12-04 21:13:00 UTC
*** Bug 601261 has been marked as a duplicate of this bug. ***
Comment 7 Max Mustermann 2012-12-04 21:18:41 UTC
From bug #601261:
The common pattern are non-working keyboard shortcuts in Non-Latin languages, like Russian, Gree, Hebrew, Hangual (2-set-Korean). Increasing Importance as many users are affected.
Also happens on Windows and Mac OS X.
Comment 8 Max Mustermann 2012-12-07 06:04:55 UTC
*** Bug 689831 has been marked as a duplicate of this bug. ***
Comment 9 Max Mustermann 2012-12-07 13:31:25 UTC
*** Bug 322696 has been marked as a duplicate of this bug. ***
Comment 10 Max Mustermann 2012-12-07 13:35:22 UTC
Created attachment 230964 [details]
Various Non-Latin keyboard layouts

To make this problem clearer for those who are not owning a Non-Latin keyboard I attached some exemplary keyboard layouts, that were often reported in this bug and its duplicates.
Comment 11 Max Mustermann 2012-12-07 13:38:09 UTC
A workaround for this (until it gets fixed eventually) is to use the menus. This works at least for GIMP and shortcuts like Ctrl+Z (Edit/Undo).
Comment 12 Denis 2013-11-11 12:13:28 UTC
*** Bug 696134 has been marked as a duplicate of this bug. ***
Comment 13 Michael Schumacher 2015-03-04 20:19:59 UTC
*** Bug 745543 has been marked as a duplicate of this bug. ***
Comment 14 Michael Schumacher 2016-05-26 13:48:41 UTC
*** Bug 765401 has been marked as a duplicate of this bug. ***
Comment 15 Siarhei Kuchuk 2016-07-12 11:08:29 UTC
Guys, i reported that bug several years ago... and i still see its here in Gimp. Could you please say are you going to make priority to it this year? i don't want to make English my primary keyboard neither install linux on VM just for your app.

i know your primary auditory is english users, but there're much other people speaking different languages that would like to use your app including me.

Could you please make at least workaround for Ctrl+C/Ctrl+V/Ctrl+X/Del buttons.
Comment 16 Siarhei Kuchuk 2016-07-12 11:24:09 UTC
I sumbmitted that issue to GTK also.
https://bugzilla.gnome.org/show_bug.cgi?id=768722
Comment 17 Mohammad Alhobayyeb 2016-07-25 17:09:07 UTC
Please fix, I am using GIMP for Arabic and I have same issue. I am using GIMP for several years now. I have to switch languages each time I want to use a shortcut. And I am using them a lot. I tried to move to Krita this month but it is not as easy as GIMP.

I am using MacBook.
Comment 18 LRN 2016-08-04 18:09:08 UTC
This is now fixed in gtk+ master. A gtk-2-24 backport is available, but it is not to be pushed until the code is better-tested. By someone other than me. On real applications. In GIMP, for example.
Comment 19 Siarhei Kuchuk 2016-08-05 11:51:17 UTC
Hi

Thanks for backport, i created bug in https://bugzilla.gnome.org/show_bug.cgi?id=769550 . Hope shortcuts finally will work for all languages.

Thanks.
Comment 20 Daniel Boles 2017-01-30 16:40:32 UTC
The fix has since been picked to GTK+ 2.24.32:
https://bugzilla.gnome.org/show_bug.cgi?id=769550#c8

I think it's safe to close this and leave the other ticket for GIMP devs to get this version of GTK+, build against it, and run their own tests.