Community
Participate
Working Groups
Tested on Redhat ver 3.0, build 27 April IES build - Create Simple project, Name it with An Arabic name. - Create a simple file, and change the keyboard layout to Arabic and insert text into the file - Press Ctrl+ S to save the file - The file is not saved, shorcut keys are not working with Arabic keyboard NB: Same problem appears with Alt+e that opens the Edit menu
Could you do me another favour? Could you run with some debugging options? You would need to create a file some on disk called "options". In it put the following 4 lines: org.eclipse.ui/debug=true org.eclipse.ui/trace/contexts=true org.eclipse.ui/trace/keyBindings=true org.eclipse.ui/trace/keyBindings.verbose=true Then, open a command prompt and run Eclipse. Start Eclipse with the following additional parameter: -debug C:\path\to\options Then recreate the problem. Include the output from the command prompt.
Created attachment 10428 [details] Traces file As per request, traces file
SWT: The Arabic key down events received by our key binding filter don't have enough information to match them up with English key bindings.
Douglas, did you actually set an arabic keyboard in your linux machine ? Heba: How do you set the keyboard ? I use: setxkbmap -layout "us,ar" -option "grp:alt_shift_toggle"
Steve, I believe you were the last one to change this code. We have a couple problems to fix here: SWT does not run Widget#setKeyState() when gdkEvent.length is greater than one. gdkEvent.length is the length of the string in UTF-8. Question: why do we do that ? I suppose we want to avoid this code from running on DBCS (Japanese, Chinese, etc) but this test also prevents the code from running on Arabic, Hebrew and several others scripts, I think that is just wrong. Second problem: in Widget#setKeyState() we call gdk_keymap_translate_keyboard_state with the same group number that came in the event, thus we translate from arabic to arabic, english to english, etc. The way we are using this call the only thing it does is to return the unshift value of a character. The problem is: we don't know what is the right group number to use, I suppose the group number assign to English is the correct one, but I'm not sure. Still I don't know how to find out which is the group number was assigned to English. It might also be possible that English is not installed. Example: The user has only German and Arabic.
In fact I am not using a command line command to set the keyboard, we use the language icon on the start menu bar. Let me know if this is not what you expect and if I should behave otherwise
That's okay Heba, you probably using gxkb (if you are running on Gnome) or kxkb (on KDE).
This should be fixed for 3.0. Please set the target milestone for this bug to a 3.0 RC build.
Felipe and Steve to consider the best (least risky) fix/workaround at this point.
It fails for me with gedit, regardless if I using kxkb (KDE applet) or gxkb (Gnome applet). Change the keyboard layout to arabic using your favorite applet and try to use Ctrl+a to select all the text in gedit. It will fail. It also fails in my C example. In only works (gedit) if the keyboard is set using setxkbmap to use multiples groups (example in comment#4), Eclipse fails all the case, you need to switch back to english to use accelerators.
Just to be clear for the submitter. This bug is being deferred to 3.0.1 since an acceptably low risk fix/workaround is not possible at this point of the 3.0 cycle.
Felipe and Steve N., Can this be fixed in 3.0.1 or will it be targeted for 3.1? Not being able to use shortcuts on Linux on these locales will be a significant problem for some users.
Steve what is resolution of this?
FH, I was under the impression that this could never be fixed, due to the way Eclipse does accelerators? This is compounded by the fact that Linux doesn't have a standard way to detect an Arabic keyboard. I know we spent a bunch of time looking at this for 3.0 and got nowhere. FH to comment.
The problem is, when the 'a' key is pressed a key down event is generate with the hardware keycode 38. Then this hardware keycode is passed to the keymap, if the keymap is english it will return 0x61 back, if the keymap is arabic it will return 0x634. Accelerators only work when 0x61 is reproduced. The linux tools to change keyboard input method operate in different ways (follow no standart), leaving the keymap in some 'random' state. A hardware keycode is translate according with 'whatever' the keymap is. There is no GTK mechanism to help with this.
Just to explicitly follow up on comment #12, it sounds like work on this will be deferred until after GTK adds support or Linux gets consistent about how accelerators are handled. Correct?
Correct. Fixing this without gtk support would require a lot of X code (bypassing gtk) which is difficult to get right.
The problem is in Widget#setKeyState(), see comment 5 in bug 61190. Removing the check "if (keyEvent.length > 1) return false;" fixes the problem.
Sorry, please ignore comment #18, I posted it in the problem pr. It should go on bug 87578.
The first part of problem described in comment 5 is fixed.
*** Bug 92069 has been marked as a duplicate of this bug. ***
This problem still remains with Eclipse 3.1 Build I20050505 on Red Hat Enterprise Linux 4.0 WS, we believe that this should be fixed for better usability of the product, We raised the severity to be "major" (thanks Heba). Is there any plan for resolution?
Amr, Please see comment #17, this will not be fixed for 3.1
*** Bug 129138 has been marked as a duplicate of this bug. ***
*** Bug 153238 has been marked as a duplicate of this bug. ***
*** Bug 213781 has been marked as a duplicate of this bug. ***
Seems that mozilla gecko devteam has managed to fix similar problem ( https://bugzilla.mozilla.org/show_bug.cgi?id=69230 ). Maybe their solution can be reused in Eclipse? If there are no other technical restrictions, of course. Cheers!
*** Bug 217394 has been marked as a duplicate of this bug. ***
since all gtk apps can handle shortcuts in any layout i think eclipse aslo must do. this bug is very annoying for me.. i hope it will be fixed soon.
4.5 years and still not fixed!!! arrgghh!! please pay attention to this bug.
Please see comments 14 and 15.
(In reply to comment #31) > Please see comments 14 and 15. > what? you are refering to comments of 4 years old! all gtk apps work great with shortcuts! get code from any gtk program. leafpad, for example.. ohh. you guys seems to be too lazy..
(In reply to comment #32) > what? you are refering to comments of 4 years old! Unfortunately, they remain true. > all gtk apps work great with shortcuts! Eclipse implements shortcuts differently. It doesn't use native menu accelerators. It uses the key down event to implement their shortcut strategy. The applets in Linux to change the keyboard layout don't use layout support from XKB, instead they change the x keymap entirely every time the layout changes. That makes impossible for us (SWT) to map the hardware key to the same keycode/character every time (it will depend on the keymap currently set in x). Thus, the shortcut implementation of Eclipse that relies always getting the same keycode/character during key down fails.
(In reply to comment #33) > The applets in Linux to change the keyboard layout don't use layout support > from XKB, instead they change the x keymap entirely every time the layout > changes. That makes impossible for us (SWT) to map the hardware key to the same > keycode/character every time (it will depend on the keymap currently set in x). I don't think this is correct. There is a little program which comes with the X server called "xev". This little utility prints details about X events, such as key presses and mouse clicks. For example, in my case, when the US and Greek keyboard layouts are changed the returned keycode is the same for the same key. pressing key "a" for the US layout returns: KeyPress event, serial 34, synthetic NO, window 0x3a00001, root 0x8b, subw 0x0, time 152990154, (713,400), root:(718,425), state 0x0, keycode 38 (keysym 0x61, a), same_screen YES, XLookupString gives 1 bytes: (61) "a" XmbLookupString gives 1 bytes: (61) "a" XFilterEvent returns: False pressing key "a" for the Greek layout returns: KeyPress event, serial 34, synthetic NO, window 0x3a00001, root 0x8b, subw 0x0, time 153025270, (340,744), root:(345,769), state 0x2000, keycode 38 (keysym 0x7e1, Greek_alpha), same_screen YES, XLookupString gives 2 bytes: (ce b1) "α" XmbLookupString gives 2 bytes: (ce b1) "α" XFilterEvent returns: False See the "keycode 38"? If so, there is a way to know which key is pressed, without worrying about the keyboard layout. Sorry I am not a java programmer myself to give more hints on how to do it. Please have a closer look at this bug. It is absolutely annoying for anyone using multiple keyboard layouts. This only problem forced me to switch to Netbeans (which does not have this issue of course).
*** Bug 271911 has been marked as a duplicate of this bug. ***
Bugs #261386 and #239690 seem to be the duplicates of this bug. Several other duplicates of this bug (61190) are marked as resolved. I haven't seen any updates to the Eclipse platform. Did you resolve this bug? I'd love to have this bug fixed! It is very annoying indeed, to switch between layouts every time.
haha, just tried NetBeans and it works flowlessly. not only hotkeys but many other things. i found it much more convenient than eclipse. so bye bye eclipse :-)
Your bug has been moved to triage, visit http://www.eclipse.org/swt/triage.php for more info.
As I see it, real useability problem here is not that shortcuts in eclipse are not working in non-latin layout, but that the layout is changed when shortcut is pressed. And this is problem in Xserver. I found related bugreport in X.org bugzilla (5 years old, you guessed it) [1]. Last comments are about "xneur" daemon which can replace layout switching by Xserver and handle layout switch on shortcut release, not on shortcut press (only for version 0.9.5, but I haven't found deb or rpm, only sources are available and I had some issues compiling them). Maybe someone will find this information useful. [1] https://bugs.freedesktop.org/show_bug.cgi?id=865
There is a working patch for xserver at xorg's bugzilla which will make layout switching shortcut work much like it does in windows OS: switch on release. Just tried it - all shortcuts at eclipse are now working like a charm. Patched version of xserver for ubuntu karmic is available somewhere on launchpad.
any news? =\
(In reply to comment #41) > any news? =\ Sorry, there is no one working on this problem.
Maybe I found where is the problem. SWT library for linux and Windows have the difference behavior. Here is an example: import org.eclipse.swt.*; import org.eclipse.swt.events.*; import org.eclipse.swt.widgets.*; public class Snippet241 { public static void main(String[] args) { Display display = new Display(); Shell shell = new Shell(display); shell.setBounds(10, 10, 200, 200); Text text1 = new Text(shell, SWT.MULTI | SWT.WRAP); text1.setBounds(10, 10, 150, 50); text1.addKeyListener(new KeyListener() { @Override public void keyReleased(KeyEvent e) {} @Override public void keyPressed(KeyEvent e) { System.out.println("keyCode: " e.keyCode); System.out.println("character: " e.character); } }); shell.open(); while (!shell.isDisposed()) { if (!display.readAndDispatch()) display.sleep(); } display.dispose(); } } When I type Russian character 'Û' ('S' in English layout ) in Windows I have: keyCode: 115 character: Û but in linux I have: keyCode: 1099 character: Û I think the problem is situated in class: org.eclipse.swt.widgets.Widget in method: boolean setKeyState (Event event, GdkEventKey keyEvent) in line: if (OS.gdk_keymap_translate_keyboard_state(OS.gdk_keymap_get_default (), keyEvent.hardware_keycode, 0, keyEvent.group, keyval, effective_group, level, consumed_modifiers)) { I changed this line: if (OS.gdk_keymap_translate_keyboard_state(OS.gdk_keymap_get_default (), keyEvent.hardware_keycode, 0, 0, keyval, effective_group, level, consumed_modifiers)) { I built SWT and changed org.eclipse.swt.gtk.linux.x86_3.6.1.v3655c.jar of my eclipse. Now I have no problems, but I don't know whether this way is right. I changed parameters by my guess. Here is jar which I built: http://files.gurinovich.com/root/java/eclipse/swt/org.eclipse.swt.gtk.linux.x86_3.6.1.v3655c.jar Here is source which I changed: http://files.gurinovich.com/root/java/eclipse/swt/org.eclipse.swt.gtk.linux.x86_3.6.1.v3655c.zip
This works only if english layout is first in the list of layouts.
(In reply to comment #44) > This works only if english layout is first in the list of layouts. Yes, that is the problem with your patch. We can't just assume that group 0 is English, or that group zero represent the physical keyboard layout. Moreover, most keyboad applets do not use XKB the way you do (I assume you set 0=English and 1=Russian). They usually set only one goup, for the current lang selected in the applet.
GdkEventKey.hardware_keycode is always same in different layouts. Probably it's better to use it, instead of OS.gdk_keyval_to_unicode?
Quick "fix". Widget.java: event.keyCode = getKeyCode(keyEvent.hardware_keycode, keyval[0]); private int getKeyCode(short hardware_keycode, int keyval) { switch (hardware_keycode) { case 43: return 104; case 55: return 108; case 57: return 99; case 38: return 97; case 39: return 115; case 40: return 100; default: return OS.gdk_keyval_to_unicode (keyval); } } But need to add cases to all keycodes... Works for me in all layouts (Russian,English)
(In reply to comment #47) > case 43: > return 104; > case 55: > return 108; > case 57: > return 99; > case 38: > return 97; > case 39: > return 115; > case 40: > return 100; Why these numbers ? You tested them and they worked for you ? Try replacing your keyboard by some other keyboard (I suspect these number would all be wrong).
magic numbers detected =) actually technique should be the same as in any other gtk app.
Why these? Very simple: http://cgit.freedesktop.org/xorg/proto/x11proto/plain/keysymdef.h For example: #define XK_S 0x0053 /* U+0053 LATIN CAPITAL LETTER S */ char c = 0x053; System.out.println("C: " + c); //output is: "C: S"
(In reply to comment #50) > Why these? Very simple: > char c = 0x053; > System.out.println("C: " + c); //output is: "C: S" Sure, it also happens to be x53 in the ascii table ;-) What we need is a legit method (using native calls) to convert a hardware keycode to keyval/unicode in the physical keyboard layout. The current method is mapping the hardware to the current logical keyboard layout. AFAIK that GTK does not provide such functionality. I also failed to find XKB calls to get the job done.
Or we can use just switch-case mapping... (In reply to comment #51) > (In reply to comment #50) > > Why these? Very simple: > > char c = 0x053; > > System.out.println("C: " + c); //output is: "C: S" > > Sure, it also happens to be x53 in the ascii table ;-) > > What we need is a legit method (using native calls) to convert a hardware > keycode to keyval/unicode in the physical keyboard layout. The current method > is mapping the hardware to the current logical keyboard layout. > > AFAIK that GTK does not provide such functionality. I also failed to find XKB > calls to get the job done.
Hm.. Probably we can use keyEvent.keyval from boolean setKeyState (Event event, GdkEventKey keyEvent) { int i = keyEvent.keyval; System.out.println(i); //output is 83 And AFAIK 83 is too S, is is possible to convert from 83?
(In reply to comment #53) > Hm.. Probably we can use keyEvent.keyval from boolean setKeyState (Event event, > GdkEventKey keyEvent) { Here is documentation for GdkEventKey http://library.gnome.org/devel/gdk/stable/gdk-Event-Structures.html#GdkEventKey GdkEventKey.keyVal can be any from this list http://www.koders.com/c/fidD9E5E78FD91FE6ABDD6D3F78DA5E4A0FADE79933.aspx so it isn't suitable. I agree with Felipe Heidrich that GTK does not provide such functionality. But this bug enrages many honest people. And unoficial fix is better then nothing. Method by Pavel Kirpichyov which uses switch (hardware_keycode) will work for specific keyboard. I think 90% of all keyboards uses the same hardware keycodes.
Here is my implementation of patch. Uses properties file to map hardware keycodes. Not suitable for official fix. For fan only!!! USE THIS PATCH AT YOUR OWN RISK!!! Documentation inside. http://files.gurinovich.com/root/java/eclipse/swt/swt-gtk-patch.tar.gz
(In reply to comment #55) > Here is my implementation of patch. Thank's a lot! Seems like working patch.
*** Bug 261386 has been marked as a duplicate of this bug. ***
*** Bug 239690 has been marked as a duplicate of this bug. ***
Has the GTK bug mentioned here been reported to GTK bug tracker? It's rather strange that eclipse can't fix such simple things, especially after 6 years since this bug was reported.
(In reply to comment #59) > Has the GTK bug mentioned here been reported to GTK bug tracker? No, this is not a bug in GTK per say. The problem is in GTK/SWT/Eclipse integration Eclipse does all the key binding work in the SWT KeyDown event. This means that SWT needs to provide the unmodified keyCode in the KeyDown event (in the keyboard layout which the keybinding was register). In the GTK key signal, the keyCode for type character in the current keyboard layout is provided. The problem when the keyboard layout is not the same. Other GTK app do not have this problem because all the key bindings are done using menu accelerators which are handled differently by GTK. > It's rather strange that eclipse can't fix such simple things, Trust me, this is not a "simple thing" See comment 15 and comment 33
Hello! Can't download patch from Pavel Gurinovich http://files.gurinovich.com/root/java/eclipse/swt/swt-gtk-patch.tar.gz maybe someone upload it somewhere else?
What if to do following: If linux SWT finds system property for example 'hardware-key-mapping=qwerty' than SWT uses predifined mapping for hardware keys. Somthing like in described in comment #47. If SWT not finds such system property it works like it works. In this case linux users only need to add line '-Dhardware-key-mapping=qwerty' into eclipse.ini file to fix this problem. Is this solution acceptable?
In mozzila done: https://bugzilla.mozilla.org/attachment.cgi?id=307428&action=diff Some applications read keys: "showkey" https://github.com/pclouds/busybox-w32/blob/master/console-tools/showkey.c
Here is my temporary solution of this problem: http://sourceforge.net/projects/lesch/
Created attachment 238984 [details] Patch key event dispatch same as Mozilla project This patch fix this bug and implements behaivor same as in Mozilla project (mentioned in comment 63). When Control key is pressed latin keycode/keyval will be used. Please review.
Also, I have simple temporary solution without patching Eclipse - https://github.com/amozzhuhin/eclipse-hotkeys-fix.
Any news? Developers, please, lets try fix this bug before tenth years boundary. :)
Just want to inform all interested in a workaround, the patch Andrey Mozzhuhin has shared with us works perfectly for me under Arch Linux x86_64. Andrew, thanks!
In my ubuntu 13.10 (Linux x86_64) this patch doesn't work for combination start from shift + alt, for example shift + alt + j. Ctrl + shift work fine. Key board switch by combination ctrl + super(win key) + Space. Second language is Russian
Thanks for replies. I updated my temporary solution on github. Now must working hotkeys with Alt and non-letter combinations like Ctrl+/. Please, test this version. I will update patch for Eclipse later.
Now work fine with all key combination
Created attachment 239557 [details] Patch key event dispatch for keys not with Latin key group Updated version of patch. Short implementation description: 1) find Latin key group at SWT startup by iterating over Latin alphabet keys and search they in active key groups; 2) on key event with pressed Ctrl or Alt find key with same hardware code and level but with Latin group, use it as result key; 3) on layout changes update Latin key group.
(In reply to Andrey Mozzhuhin from comment #72) > 1) find Latin key group at SWT startup by iterating over Latin alphabet keys > and search they in active key groups; Can it be that no Latin group is available at all? (e.g. when user only enabled a Russian keyboard layout)
(In reply to Lina Kemmel from comment #73) > Can it be that no Latin group is available at all? (e.g. when user only > enabled a Russian keyboard layout) Yes, it is possible. In this case my patch will select first available key group (zero index), and will try translate keys in this group on key press. It is not possible get work Latin shortcuts, because we don't know keys layout. But manual binding to non-Latin keys in Eclipse Preferences (General/Keys) will be one solution to get shortcuts work. Also, I have pushed this patch to Gerrit [1] and will be happy if someone review it. [1] https://git.eclipse.org/r/#/c/22713/
(In reply to Lina Kemmel from comment #73) > (In reply to Andrey Mozzhuhin from comment #72) > > 1) find Latin key group at SWT startup by iterating over Latin alphabet keys > > and search they in active key groups; > > Can it be that no Latin group is available at all? (e.g. when user only > enabled a Russian keyboard layout) In addition I've checked this configuration on Ubuntu (under Unity and KDE sessions) with GTK and Qt applications and all shortcuts with letter doesnt works in all application.
I tested the patch on RHEL6 x86 GNOME with different keyboard layouts and found it to be working fine (thanks!), except for one case: If there are more than 1 active Latin groups, say QWERTY and Dvorak, only the keyboard shortcuts matching the first one (QWERTY in my case) are working (since only the first one is deemed "Latin keyboard"). But when the effective group is Dvorak, I still have to use keys conforming with the QWERTY layout. That's rather an edge case, but previously it used to work with individual keys of each particular effective Latin group. I think Widget#setKeyState, after retrieving OS.gdk_keyval_to_unicode, should check whether it's a Latin code point or not, and omit any special processing if it's Latin. Some other comments: - Caching KBD mapping and special handling in general not needed when there's just one active group (either Latin or non-Latin). - Caching the mapping when Display is being initialized is probably not necessary and could be postponed until actual key press with Ctrl or Alt occurs. Also, perhaps you could only cache the mapping just for those actually pressed keys (on the fly). ---------------------- I think that cases that actually use IME (e.g. Chinese, Japanese, Korean) should also be tested (I didn't test them).
(In reply to Lina Kemmel from comment #76) > I tested the patch on RHEL6 x86 GNOME with different keyboard layouts and > found it to be working fine (thanks!), except for one case: > > If there are more than 1 active Latin groups, say QWERTY and Dvorak, only > the keyboard shortcuts matching the first one (QWERTY in my case) are > working (since only the first one is deemed "Latin keyboard"). But when the > effective group is Dvorak, I still have to use keys conforming with the > QWERTY layout. > I think about this but didn't knows that keyboards with both QWERTY and Dvorak is exists. > That's rather an edge case, but previously it used to work with individual > keys of each particular effective Latin group. > > I think Widget#setKeyState, after retrieving OS.gdk_keyval_to_unicode, > should check whether it's a Latin code point or not, and omit any special > processing if it's Latin. > I agree and fix this (but non-letter hotkeys will not work in other layouts). > Some other comments: > > - Caching KBD mapping and special handling in general not needed when > there's just one active group (either Latin or non-Latin). > I don't find GDK function for getting count of available layouts. > - Caching the mapping when Display is being initialized is probably not > necessary and could be postponed until actual key press with Ctrl or Alt > occurs. Also, perhaps you could only cache the mapping just for those > actually pressed keys (on the fly). We can't work on fly for pressed keys because non-letter hotkeys must work same as letter hotkeys - current layout must be ignored and Latin char on key is used. Otherwise when we get Ctrl+. we will didn't know is it '.' in Latin layout or it is '/' in Russian layout. > ---------------------- > > I think that cases that actually use IME (e.g. Chinese, Japanese, Korean) > should also be tested (I didn't test them). I didn't test too. Need somebody who use IME. Review of this patch is in progress at Gerrit (https://git.eclipse.org/r/#/c/22713/). Lina, please can you post your comments in Gerrit for other reviewers?
(In reply to Andrey Mozzhuhin from comment #77) > (In reply to Lina Kemmel from comment #76) > > We can't work on fly for pressed keys because non-letter hotkeys must work > same as letter hotkeys - current layout must be ignored and Latin char on > key is used. Otherwise when we get Ctrl+. we will didn't know is it '.' in > Latin layout or it is '/' in Russian layout. > This in fact implies the same treatment as literals in multiple Latin layouts. Should a hotkey be associated with a hardware key or keyval (code point)?
gedit for example seems to tolerate both. For example, in case of 2 Latin groups, both of |Alt + F|'s (associated with distinct hardware keys in each layout) work when either group is effective.
(In reply to Lina Kemmel from comment #78) > This in fact implies the same treatment as literals in multiple Latin > layouts. Should a hotkey be associated with a hardware key or keyval (code > point)? I think hotkeys must be independent from current layout. People remember hotkeys as fingers positions. If hotkeys will depend on layout user will remember more and more positions. Can someone explain me how people can use multiple layouts with the same letters? For example, on Russian keyboard keys '.' and ',' exists in English and Russian layout but many-many people use only one of group and every time switch from one layout to another only for pressing '.' because doing layout switch is easy then remember more finger positions. > gedit for example seems to tolerate both. For example, in case of 2 Latin > groups, both of |Alt + F|'s (associated with distinct hardware keys in each > layout) work when either group is effective. Now I think it is a bug. For one key can be binded multiply hotkeys from different layouts and pressing that keys will leads to unexpected behavior.
(In reply to Andrey Mozzhuhin from comment #80) > (In reply to Lina Kemmel from comment #78) > > This in fact implies the same treatment as literals in multiple Latin > > layouts. Should a hotkey be associated with a hardware key or keyval (code > > point)? > > I think hotkeys must be independent from current layout. People remember > hotkeys as fingers positions. If hotkeys will depend on layout user will > remember more and more positions. Sure, all the world exists this way during ages! :) We have started to processed scan codes rather than symbols at MS DOS era, if you remember...
(In reply to Andrew Gaydenko from comment #81) > Sure, all the world exists this way during ages! :) We have started to > processed scan codes rather than symbols at MS DOS era, if you remember... (In reply to Andrew Gaydenko from comment #81) > (In reply to Andrey Mozzhuhin from comment #80) > > (In reply to Lina Kemmel from comment #78) > > > This in fact implies the same treatment as literals in multiple Latin > > > layouts. Should a hotkey be associated with a hardware key or keyval (code > > > point)? > > > > I think hotkeys must be independent from current layout. People remember > > hotkeys as fingers positions. If hotkeys will depend on layout user will > > remember more and more positions. > > Sure, all the world exists this way during ages! :) We have started to > processed scan codes rather than symbols at MS DOS era, if you remember... But hotkeys support in Qt and GTK works differently - all possible characters from all available layouts will be used to match hotkey. As I understand Lina Kemmel considers SWT/Eclipse hotkeys must be implemented by this way. Currently I'm trying to work on new patch with this behavior.
The bug still exists in eclipse (just updated): Version: Luna Service Release 1a (4.4.1) Build id: 20150109-0600 I use US/GR/RU layouts, Ubuntu 14.04 64bit.
Of course, 4.4.2 still expose this great bug. And Andrey Mozzhuhin's fix still does work as expected. But now we have days of the SWT/gtk3 adoption beginning. As a result of the bug, many Linux Eclipse users will not report any feedback related to gtk3 adoption. as far as the fix is gtk2-oriented. [1] https://github.com/amozzhuhin/eclipse-hotkeys-fix
The bug still exist Eclipse Standard/SDK Version: Kepler Service Release 2 Use EN/RU/UK layouts Debian 8 Jessie+ XFCE 4.10
I solved this problem by migrating to other IDEs ;-)
Just want to inform affected users, Andrey Mozzhuhin has kindly prepared also a GTK3 version of his fi[: https://github.com/amozzhuhin/eclipse-hotkeys-fix
please increase severity of this bug, as it is app breaker. i came from windows to debian and brought with myself ctrl+shift changer layout and i'm confused eclipse is failing on it's main platform linux while being good on windows. __ eclipse mars 4.5.1 platform 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1+deb8u4 (2015-09-19) x86_64 GNU/Linux
I resurrect patch which I mentioned few years ago in this topic. It is not the solution but a crutch. Which patches SWT jar and adds hardcoded hardware-keyboard-code to swt-keycode map. Patch its sources and short instruction can be downloaded here https://sourceforge.net/projects/lesch/ Current version 1.0.5 is able fix only eclipse v4.5.1 (Mars 1) but In nearest future I plan to extend this patch to fix all v4.* eclipses.
SWT Developers, please check the Patch Set 5 (and short description in my last comment) at https://git.eclipse.org/r/#/c/22713/.
When can we expect inclusion of the fix?
I had a quick test with Russian layout. Ctrl+s indeed doesn't save a dirty editor. The submitted patch needs an update before we can merge it, as platforms like Motif are no longer supported. I could review/merge an updated patch. I can test with Russian Layout, and if somene explains how, with an Arabic layout also.
Leo, thank you for your interest in this bug. Unfortunately, my attempts to solve this problem in a simple way were rejected. In patch sets 1-4, I tried to limit myself to changes only in the GTK backend of the SWT library. There, I was make substitution of the current character in the key press events to the corresponding character from the Latin keyboard layout in case of pressing the keyboard shortcuts together with Ctrl, Alt and Shift modifiers. But this little dirty hack was rejected because it did not allow processing non-latin hotkeys. In order to leave support for both Latin and non-Latin hotkey shortcuts, we need to take this processing out of the SWT library to the application level. That is, the SWT library should provide an interface for obtaining a list of characters from all supported layouts for the interested key. So for example it's done in GTK [1] and Qt [2]. Such variant I made in Patch set 5. But it is only an interface to obtaining the characters for the key. In order to fix the bug in Eclipse, we will need to make changes into the Eclipse Platform hotkeys processing after we get the interface. Thus, the solution of the problem is rather labor-intensive than it may seem at first glance. I run into the architectural solutions of the SWT library here. So I cant fix it by myself and I need an agreed solution from SWT developers. [1] https://developer.gnome.org/gdk3/stable/gdk3-Keyboard-Handling.html#gdk-keymap-get-entries-for-keyval [2] https://github.com/qt/qtbase/blob/dev/src/gui/kernel/qplatformintegration.cpp#L445
(In reply to Andrey Mozzhuhin from comment #93) > Leo, thank you for your interest in this bug. > > Unfortunately, my attempts to solve this problem in a simple way were > rejected. In patch sets 1-4, I tried to limit myself to changes only in the > GTK backend of the SWT library. There, I was make substitution of the > current character in the key press events to the corresponding character > from the Latin keyboard layout in case of pressing the keyboard shortcuts > together with Ctrl, Alt and Shift modifiers. But this little dirty hack was > rejected because it did not allow processing non-latin hotkeys. > > In order to leave support for both Latin and non-Latin hotkey shortcuts, we > need to take this processing out of the SWT library to the application > level. That is, the SWT library should provide an interface for obtaining a > list of characters from all supported layouts for the interested key. So for > example it's done in GTK [1] and Qt [2]. Such variant I made in Patch set 5. > But it is only an interface to obtaining the characters for the key. In > order to fix the bug in Eclipse, we will need to make changes into the > Eclipse Platform hotkeys processing after we get the interface. > > Thus, the solution of the problem is rather labor-intensive than it may seem > at first glance. I run into the architectural solutions of the SWT library > here. > > So I cant fix it by myself and I need an agreed solution from SWT developers. > > [1] > https://developer.gnome.org/gdk3/stable/gdk3-Keyboard-Handling.html#gdk- > keymap-get-entries-for-keyval > [2] > https://github.com/qt/qtbase/blob/dev/src/gui/kernel/qplatformintegration. > cpp#L445 Hmm. This bug is currently the highest voted SWT-gtk bug. It seems it's worth spending time on. I haven't researched the specifics of the above, but I'm an SWT on Gtk contributor, and can review/merge suitable patches and can give some time and attention to this bug. I haven't done cocoa/win32 development, so my influence on those platforms are limited. So my questions being: 1) Is this bug specific to Swt/Linux? I.e, does the above actually work well on Cocoa/Windows, do you know? (Comment #88 suggests it works on windows). 2) If specific to Linux, is there a solution that would involve only "gtk" side of SWT (a semi decent one..)?. I don't have commit rights to platform, but I could push for having relevant patches merged.
(In reply to Leo Ufimtsev from comment #94) > 1) Is this bug specific to Swt/Linux? I.e, does the above actually work well > on Cocoa/Windows, do you know? (Comment #88 suggests it works on windows). I made some investigation on Windows platform and it depend on that is "work well". For example, key "/" ("?" with SHIFT pressed) in Russian QWERTY layout produce "." ("," with SHIFT pressed) and on Windows this key trigger different action dependently on current keyboard layout. Also SWT buttons with accelerators (ALT+<&char>) works only in layout of accelerator char (unlike menu that work independently of current keyboard layout). But mainly Eclipse hotkeys works on Windows. I think it will be cool if Eclipse on Linux will have at least this functionality. > > 2) If specific to Linux, is there a solution that would involve only "gtk" > side of SWT (a semi decent one..)?. I don't have commit rights to platform, > but I could push for having relevant patches merged. I have made patch based on my previous patch set 4 that touch only GTK part of SWT. In this patch SWT will find Latin layout group (Display.findLatinKeyGroup) and use it always in Widget.setKeyState to get event keyCode. Review, please.
(In reply to Andrey Mozzhuhin from comment #95) > Review, please. ~ Review in progress.
Created attachment 269307 [details] Snippet with Russian menu.java Modified snippet with Russian menu for patch verification.
Current patch looks quite promising. (Patch set #7). Eclipse's shortcuts like Ctrl+s work when Russian keyboard layout is active. MenuItem accelerators work if menu is russian E.g: (Фаил) (see snippet 29). This is also true for when russian is the only language on the system. Just needs minor polish and I think the patch can probably be merged. (Pending review of final patch)
(In reply to Andrey Mozzhuhin from comment #95) > (In reply to Leo Ufimtsev from comment #94) > > 1) Is this bug specific to Swt/Linux? I.e, does the above actually work well > > on Cocoa/Windows, do you know? (Comment #88 suggests it works on windows). > > I made some investigation on Windows platform and it depend on that is "work > well". For example, key "/" ("?" with SHIFT pressed) in Russian QWERTY > layout produce "." ("," with SHIFT pressed) and on Windows this key trigger > different action dependently on current keyboard layout. Also SWT buttons > with accelerators (ALT+<&char>) works only in layout of accelerator char > (unlike menu that work independently of current keyboard layout). > > But mainly Eclipse hotkeys works on Windows. I think it will be cool if > Eclipse on Linux will have at least this functionality. I think so long as at least the main things like Ctrl+s,c,x,v work, then we have success. Improvements can be made later.
We are experiencing maven build issues. Need to have that fixed first.
@ SWT Developers involved. I've tested the submitted patch: https://git.eclipse.org/r/#/c/22713/ (revision 9) The patch looks good to me and as far as I can see, all mentioned concerns were addressed. I.e: With an English/Russian keyboard layout, on my Russian keyboard layout - I can now activate hotkeys like "ctrl+s" to save. - Menus that trigger on Russian keys e.g "&Фаил" still work fine. (e.g see attached "Snippet with Russian menu.java") This patch only touches Gtk code. If there are no objections, I will merge it in early August, and if it works well back port it to 4.7.1 in September.
Gerrit change https://git.eclipse.org/r/22713 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=29ab8186773c35c49890a2c3a15f8f7b752eced9
Patch merged into Master. Newest master build tomorrow should include the fix: http://download.eclipse.org/eclipse/downloads/ We'll let folks test the patch in master. If everything works well, then I'll backport at end of August.
(In reply to Leo Ufimtsev from comment #103) > Patch merged into Master. > > Newest master build tomorrow should include the fix: > http://download.eclipse.org/eclipse/downloads/ > > We'll let folks test the patch in master. If everything works well, then > I'll backport at end of August. I see API error on this method (missing @since): org.eclipse.swt.widgets.Display.findLatinKeyGroup(). Please fix.
(In reply to Andrey Loskutov from comment #104) > (In reply to Leo Ufimtsev from comment #103) > > Patch merged into Master. > > > > Newest master build tomorrow should include the fix: > > http://download.eclipse.org/eclipse/downloads/ > > > > We'll let folks test the patch in master. If everything works well, then > > I'll backport at end of August. > > I see API error on this method (missing @since): > org.eclipse.swt.widgets.Display.findLatinKeyGroup(). Please fix. Thank you for spotting this. I cannot get the warning to reproduce in my setup, and I've enabled all warnings for api that I'm aware off. Would it be sufficent to add a " @noreference This method is not intended to be referenced by clients." tag?
(Btw, maybe "public int getLatinKeyGroup" should be protected instead of public).
(In reply to Leo Ufimtsev from comment #105) > (In reply to Andrey Loskutov from comment #104) > > I see API error on this method (missing @since): > > org.eclipse.swt.widgets.Display.findLatinKeyGroup(). Please fix. > > I cannot get the warning to reproduce in my setup, and I've enabled all > warnings for api that I'm aware off. Are you sure you have set correct API baseline? It must be 4.7, not current platform. > Would it be sufficent to add a " @noreference This method is not intended to > be referenced by clients." tag? See below. (In reply to Leo Ufimtsev from comment #106) > (Btw, maybe "public int getLatinKeyGroup" should be protected instead of > public). You probably mean "maybe "protected int getLatinKeyGroup" should be *package* protected instead of protected" => any yes, this is the right solution.
(In reply to Andrey Loskutov from comment #107) > (In reply to Leo Ufimtsev from comment #105) > > (In reply to Andrey Loskutov from comment #104) > > > I see API error on this method (missing @since): > > > org.eclipse.swt.widgets.Display.findLatinKeyGroup(). Please fix. > > > > I cannot get the warning to reproduce in my setup, and I've enabled all > > warnings for api that I'm aware off. > > Are you sure you have set correct API baseline? It must be 4.7, not current > platform. Hmm. I re-created it based on my current platform: Eclipse SDK Version: Photon (4.8) Build id: I20170802-0800 OS: Linux, v.4.13.0-0.rc3.git1.2.fc27.x86_64, x86_64 / gtk 3.22.16, WebKit 2.16.4 Still doesn't complain about that method. Hmmm :-|? > > > Would it be sufficent to add a " @noreference This method is not intended to > > be referenced by clients." tag? > > See below. > > (In reply to Leo Ufimtsev from comment #106) > > (Btw, maybe "public int getLatinKeyGroup" should be protected instead of > > public). > > You probably mean "maybe "protected int getLatinKeyGroup" should be > *package* protected instead of protected" => any yes, this is the right > solution. As a note there are two methods: protected int findLatinKeyGroup () { public int getLatinKeyGroup () { Suggestion is to 1) Add @noreference to findLatinKeyGroup 2) s/public/protected for getLatinKeyGroup
(In reply to Leo Ufimtsev from comment #108) > Suggestion is to > 1) Add @noreference to findLatinKeyGroup > 2) s/public/protected for getLatinKeyGroup I think findLatinKeyGroup() must be private, getLatinKeyGroup() - package-private without @noreference. Sorry for mistake. Leo, I need to refresh my patch or you fix it?
(In reply to Andrey Mozzhuhin from comment #109) > (In reply to Leo Ufimtsev from comment #108) > > Suggestion is to > > 1) Add @noreference to findLatinKeyGroup > > 2) s/public/protected for getLatinKeyGroup > > I think findLatinKeyGroup() must be private, getLatinKeyGroup() - > package-private without @noreference. > > Sorry for mistake. > Leo, I need to refresh my patch or you fix it? Feel free to submit a patch if you like, you seem to know your code better :-), I'll review/merge next week when master is open again.
New Gerrit change created: https://git.eclipse.org/r/102720
Gerrit change https://git.eclipse.org/r/102720 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=48fba1b7975d96270c59d30366c8f0e6f7a14d83
~Scheduled for backport sometime next week. 4.7.1 RC1 is ~Aug 18th ish.
New Gerrit change created: https://git.eclipse.org/r/103068
Gerrit change https://git.eclipse.org/r/103068 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=5257854180d0a7bece27a5008f099a50c45faadf
New Gerrit change created: https://git.eclipse.org/r/103119
Gerrit change https://git.eclipse.org/r/103119 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=3d437018e83f5495163427612f671fd452804c4d
Followup patch merged. To be tested and then backported next week-ish.
We are in 4.7.1 RC3 week already, suggest we move this to 4.7.2.
New Gerrit change created: https://git.eclipse.org/r/104122
(In reply to Eclipse Genie from comment #120) > New Gerrit change created: https://git.eclipse.org/r/104122 Thank you for backport submission. Looks like we'll have to wait for 4.7.1 to be released and then merge it into 4.7.2. Pending till 4.7.1 was released.
Gerrit change https://git.eclipse.org/r/104122 was merged to [R4_7_maintenance]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=d40fd830628d05bf6ba6f28c542d913f5eb445e6
(In reply to Eclipse Genie from comment #122) > Gerrit change https://git.eclipse.org/r/104122 was merged to > [R4_7_maintenance]. > Commit: > http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/ > ?id=d40fd830628d05bf6ba6f28c542d913f5eb445e6 Backport merged. Should be available in 4.7.2. Thank you Andrey Mozzhuhin so much for your contribution, the international crowd will surely appreciate. A news item would help advertise this feature. Feel free to submit a new & noteworthy entry if you like: https://git.eclipse.org/c/gerrit/www.eclipse.org/eclipse/news.git/ (Maybe into 4.8 M3?) I'll be happy to review.
Verified with build M20171108-1700 on Ubuntu 16.04.
*** Bug 496205 has been marked as a duplicate of this bug. ***
*** Bug 516480 has been marked as a duplicate of this bug. ***
