Community
Participate
Working Groups
Some key strokes shift the input mode by default in GTK, which breaks the way the KeySequenceText widget is supposed to work. One example is Ctrl+Shift+F. Instead of the desired character, a strange other character is inserted, and the key sequence is not modified. This character cannot be deleted. STEPS TO REPRODUCE: 1.) Open the KeysPreferencePage and change focus to the KeySequenceText widget. 2.) Type Ctrl+Shift+F ACTUAL RESULTS: An underlined 'F' is inserted in the text widget, and the key sequence is not affected. EXPECTED RESULTS: Ctrl+Shift+F should be inserted, and the key sequence updated.
There are two possible fixes. 1.) Convince SWT to perform a miracle. 2.) Rewire it to be a Button, which cannot have its input mode switched. This has two major complications. First of all, text on a button does not scroll. Secondly, ampersand does not work at all well.
*** Bug 42076 has been marked as a duplicate of this bug. ***
----- FROM BUG 42076 ----- I have found that this bug exists in I20030717 (which predates the new key binding architecture), from which I can only assume that it is not related to anything we've done (at least with the key binding work). markusle says: The reported bug is unfixable and exist in I20030717, then this bug must exist in the build with: Build ID: 200307300800 Right? If so then I have to say this bug in another bug, because My problem don't exist in: Build ID: 200307300800 ----- END BUG 42076 ----- I have since confirmed that I see the same bug on I20030730 using IBM's VM. I'll test using Sun's VM. Are you using a German keyboard?
Note: This bug applies to all text entry widgets in GTK. This includes StyledText and Text widgets.
Yes I use a german keyboard, but (perhaps unrelated): I redefined in a Linux konsole window the environment variables: LANG=de_DE@euro LANGUAGE=german to LANG=en LANGUAGE=english and got the same problems ... .
Doug, this bug applies to Text, Combo (they both have native input method support) and Canvas as long as the flag NO_FOCUS is not set (StyledText is subclass Canvas). Markusle: Try to run the command line "GTK_IM_MODULE=xim" before running eclipse, should workaround the problem for you.
Sorry to say, but GTK_IM_MODULE=xim makes no difference for me, i.e.: still no keys defined in the preferences dialog. Tried with eclipse-SDK-N20030827-linux-gtk.zip Perhaps you want to know the exact version of my self complied gtk2.2, but I have no idea how to get it ... :-(
Just confirmed that Ctrl+Shift+7 inserts an underlined 7 on GTK using Sun's JDK 1.4.2 using I200307300800. This input mode problem (feature?) has definitely been around for a while. Anyone looking at this bug might also be interested in Bug 42042, which deals with particular problems we're having with foreign keyboards and shifted characters using the new key binding architecture.
Yes, input method feature, you can hold CTRL+SHIFT down and then type any unicode value that you get the respective glyph for that. In the Java Editor: Try: CTRL+SHIFT 3042 -> should get japanese hiragana letter a Try: CTRL+SHIFT 644 (release buttons) + (press again) CTRL+SHIFT 627 -> shold get arabic ligature lam-alef. I'm assuming that you have good fonts installed in your system otherwise you would get a box glyph with a unicode number inside.
Felipe: could you provide a link to some document describing this input mode functionality? Also, why does input mode stuff happen for alpha sequences, like "Ctrl+Shift+F" and "Ctrl+Shift+D", but not others like "Ctrl+Shift+G" and "Ctrl+Shift+H"? Thanks.
I would need to look around for documentation (google ;). I've tested and it seems GTK input method likes to eat CTRL+SHIFT e,a,f,c,b and all the number.
On my german keyboard I have the following behaviour with Build: 200307300800: ------------------------------------------------------------------ CTRL+SHIFT+59 --> Y CTRL+SHIFT+5A --> Z CTRL+SHIFT+6D --> m CTRL+SHIFT+6F --> formats my java text (as I expected it from CTRL+SHIFT+F) CTRL+SHIFT+6A --> j CTRL+SHIFT+70 --> inserts a comment '// =' as I expect it from CTRL+SHIFT+7 ------------------------------------------------------------------- How can a method decide what the the key sequence CTRL+SHIFT+F means: insert ascii char 0xF OR execute key bound command?
Makes sense now... I guess I'm just slow. a,b,c,d,e,f,digits are all consumed cause they are all hexa digits used to composed unicode chars. markusle: I can't tell you what is happening to you cause I don't know what the application is doing on top of SWT. CTRL+SHIFT+F can be accelerator and run before the input method. CTRL+SHIFT+F can be a keylistener which was hooked in a widget which doesn't have input method.
felipe: I poked around a bit on Google myself, I was hoping you would have better luck than I. I did find these tidbits in the API: "The GtkEntry widget is a single line text entry widget. A fairly large set of key bindings are supported by default...." "http://developer.gnome.org/doc/API/2.0/gtk/GtkEntry.html" "http://developer.gnome.org/doc/API/2.0/gtk/gtk-Bindings.html" Is it possible to permit us to turn off the special input mode stuff? Though, as I think about it more, it my be better to provide localized key bindings for the GTK widget set. Arg. Is it better to maintain key binding consistency or consistency with the native widget behaviour? markusle: Interesting. I do this on a US keyboard and it inserts an 'o' character into my text.
Please don't fool me; perhaps I'm misunderstood: OK their are keylistener(s) and accelerator(s) and each want to do (perhaps) different things with the keysequence (CTRL+SHIFT+F), and in theory a arbitrary subset of this code pieces do their job in an arbitrary order - and that is OK. But if a user types in a given context a keysequence CTRL+SHIFT+F their is fixed expectation on the result of that keysequence, and in the context "Java-editor" the outcome of the keysequence is ambiguous (at least 3 possible cases: (Insert-Unicode), (Exceute command) or (execute command AND insert unicode). So I think this kind of unicode insertion will never work without problems in an environment with defineable key bindings.
The problem is that there are two main layers of key processing (that are relevant to this), and one additional one that causes problems in GTK. In a generic system, keys are processed globally by the command architecture; these are the Eclipse key bindings. After this, if nothing has happened, keys are sent to the widget itself for processing. The native widget might have key bindings of its own (e.g., "Ctrl+A" selects all). In GTK, there is an additional layer, which switches input modes. Certain key strokes are trapped by GTK before reaching the global command architecture (before even reaching SWT). At the moment, we don't have an easy way to disable this layer, and so some key strokes can't effectively be bound, such as "Ctrl+Shift+F". So, yes, there is a conflict which has no simple solution. The question is which of the GTK and Eclipse key bindings *should* have preference, and then how do we go about implementing that. (In general, though, I feel we shouldn't do two actions for one key stroke. Overloading a key stroke could be confusing.)
"Is it possible to permit us to turn off the special input mode stuff? " I don't think we should do that, this is no a bug but feature that GTK user expected to have. I also don't think we turn it off/ "Though, as I think about it more, it my be better to provide localized key bindings for the GTK widget set." I believe UI team already has keybinding according with locale/platform. For example: Control+space used by JDT to open to code assistent is used on Linux/Chinese to start the input method, therefore in this locale/platform the accelerator to fire the code assistent is reasigned to Control+/ (I think).
Tod: can we get other groups to back off on Ctrl+Shift+[0-9A-F] as key bindings for GTK? I'm inclined to agree that we shouldn't be breaking the native widget manner of operation. The following are the bad bindings on a US keyboard. Note that some other key bindings can become problematic on foreign keyboards (e.g., Ctrl+/ on a Swiss German keyboard). Ctrl+Shift+B Add/Remove Breakpoint Ctrl+Shift+E Delete to End of Line Ctrl+Shift+F Format
Chris McLaren, Tod Creasey and myself are leaning toward providing platform-specific key bindings that will remove collisions with the native GTK input mode key bindings. Users on Linux-GTK will not be able to bind to Ctrl+Shift+[0-9A-F] nor will they have any default bindings set to those values.
*** Bug 26361 has been marked as a duplicate of this bug. ***
From Bug 26361, please consider the "Ctrl+Fn" as reserved under KDE.
FYI: Why GTK use Ctrl+Shift: " ------- Additional Comments From Owen Taylor 2001-06-07 15:26 ------- The <ctrl><shift> combo isn't available, because that is used (by ISO standard) for Unicode entry. " http://bugzilla.gnome.org/show_bug.cgi?id=50770
Going on to read the ISO document, it appears the space is also recommended as a "sticky" key for UTF input. GTK doesn't seem to implement this currently.
*** Bug 42804 has been marked as a duplicate of this bug. ***
Appended comments to "http://bugzilla.gnome.org/show_bug.cgi?id=82011" to let them know that this is causing problems on our side.
Created attachment 6221 [details] raw list of platform-specific key bindings These are the key bindings I am aware of for various operating systems, window managers, and widget toolkits. It would probably be an idea to publish these on the platform-ui website. That way we have something to point at when people ask for crazy things. ;)
Created attachment 6223 [details] sorted list of platform-specific key bindings Sorted the individual sections to make it easier to use.
Since 200307300800 this bug blocks me to use new builds of eclipse-gtk, so please make the key-handler of eclispe take priority over the keyhandler of gtk. That's how eclipse works in build 200307300800! I think most users need CRT+SHIFT+F (+B,...) more, than the iso-character input method of gtk. If you think that is not the case, please make it configurable until you find a solution you like. I think taht should only change a 10 lines of swt-specific c-code.
markusle: we try to leave widget toolkits as they were meant to function. Even if the functionality could be suppressed, I'm not sure we'd want to. However, we have asked GNOME for a means to do so -- as this is particularly irritating for GTK users. If you are already aware of a way to suppress the special input mode, please provide us with some sample code. We have raised our concerns over the unusual side effects of these key bindings with GNOME. If have concerns as well, please add them to "http://bugzilla.gnome.org/show_bug.cgi?id=82011". Our current proposed solution is to provide platform-specific key bindings for GTK -- switching "Ctrl+Shift+[BDF]" to something else. This change has been held back from M4, but will probably be dealt with by M5. You can always remap these keys yourself. For example, I would recommend remapping "Ctrl+Shift+" to "Alt+Shift+". I'm sorry this is causing you frustration.
Your current proposed solution is to provide platform-specific key bindings for GTK has the idea to give a eclipse-gtk user the feeling he is working with a gtk application; right? I believe there are more user who like to have (on each plattform motif, gtk, windows) the same eclipse keys. For example: the chief programmer skips from maschine to maschine and "helps" its team members. Such persons prefere a homogenously keyboard layout or a switch for such an layout). So again: Please make this choice configureable on the dialog Windows>preferences>workbench>keys. The reason why I don't like to redefine my keys is simlilar to that of a chief programmer: If I work with a maschine of a friend, then I have to learn his keyboard layout, that is probably no fun. And he don't like if I redefine his keyboard layout. By the way: Linux user have to fight with the most different keyboard layouts and are far way from an homogenous application behaviour, so your effort to keep the gtk-feeling is probably not as important as you think).
My last posting to this bug was perhaps a little bit dark and negative (and ignored); the reason is that I did not kown extactly what I tried to say. I think now I know it: Your current proposed solution tries to embbed eclipse as smooth as possible in the users working environment; and you assume that the environment is MOTIF, GTK, Windows, and perhaps a few more. I think that this assumption is not correct, because there are users with a work environment "eclipse" perhaps on different GUIs (Motif,gtk,...). I define the working environment as the place where I work most of the time. Now eclispe is no file browser, or another "5 minutes up 5 hours down" application, in that sense eclispe has an right of an own keybinding. And as an result eclispe keybings definition should not define which key has which function, but also if this function takes precdence over the GUI commands or not. This "flag may exist on a per key or per key-table level. Another concrete example: I write a programm in C and want to debug it, on Windows, Linux (GTK), Linux (Motif); then it is nice to have the same eclipse keybindings on each system. Yes I know ..., but perhaps remote debugging is too slow....8-(
As we are considering a new configuration for the keyboard shortcuts, this has become part of this. The new configuration is available in today's integration build (I20031202); it is called "Standard (3.) - NEW!". If you wish to provide feedback, please provide it in Bug 37934. Format is no longer "Ctrl+Shift+F", it is "Ctrl+K Ctrl+F" -- on all platforms. Keyboard shortcuts no longer use native accelerators.
We have not agreed on moving to the proposed configuration. Shouldn't this be left open until we do?
Moving to M7 so that I can the status of the new configuration at that time.
We are deferring the new key configuration.
I've allowed "Ctrl+Shift+[A-F]" to be placed on the menu on GTK only. I've not allowed the digits [0-9], as I have concerns about how these will be processed by the widget toolkit as opposed to our key binding service. Though, this is technically possible. This allows these key bindings to circumnavigate GTK's weird input mode.
see comments which follow by Tom Eicher.
Just tried I20040224-1215 and it does not appear to work. I can neither enter the Ctrl+Shift+ combos in the key binding preferences page, nor inside the Java / Text editors.
You will not be able to define it in the keys preference page, and there is no workaround for this. See Bug 46580, or bring it up with GNOME/GTK. :) It works if you define it in XML.
Verified in I200403240800 1.) Copied "Ctrl+Shift+F" into the clipboard 2.) In the keys preference page, pasted from the clipboard into the key sequence widget to bind "Format" to "Ctrl+Shift+F". 3.) Mucked up the formatting in a source file, and pressed "Ctrl+Shift+F". Formatting was applied.
*** Bug 65163 has been marked as a duplicate of this bug. ***
*** Bug 68749 has been marked as a duplicate of this bug. ***
*** Bug 76252 has been marked as a duplicate of this bug. ***
