Description of problem: I cannot write in Russian in java aplications. When I change the layout it looks like I didn't this. It continues to write using English keyboard layout. I native applications all works fine. Version-Release number of selected component (if applicable): Name : java-1.6.0-openjdk Version : 1.6.0.0 Release : 0.18.b09.fc9 How reproducible: * I installed my system to be in Russian: * I have installed system-config-language-1.3.1-2.fc9.noarch package where I changed the language to russian (the environment variable LANG=ru_RU.utf8). * I switched on compiz-fussion and emerald. * I use KDE 4.1 * I installed kde-l10n-Russian and configured in System Config of KDE (I tested this do not touch the problem). * I installed NetBeans 6.1 which is running on openJDK not SUN JDK downloaded from their site. * Alternatives I didn't changed. /usr/bin/java refers to /usr/lib/jvm/jre-1.6.0-openjdk/bin/java * Netbeans runs from /usr/lib/jvm/jdk-1.6.0-openjdk/bin/java * When I edit any file in Netbeans I cannot write comments, nor in other dialogs of it. I tried other applications: * SquirrelSQL (http://www.squirrelsql.org) it is localized on Russian. It shows all messages in Russian but when I switch layout to Russian it continues to write using English layout. (It uses /usr/lib/jvm/jre-1.6.0-openjdk/bin/java) * Azuereus (use /usr/lib/jvm/jre-1.6.0-openjdk/bin/java) all works fine. * Eclipese. All works fine. To fix this problem in Netbeans startup script (before running java) I added the line: LANG=en_US.utf8 Actual results: When I switch to Russian layout I continue writing in English layout. The layout indicator in tray shows Russian layout. Expected results: When I change to Russian layout I should write in Russian using Russian layout not English.
Confirming the same behavior in current Rawhide as well
I have this bag too. Additional, if installed SUN JDK, this bug don`t disappear. I think, this is trouble with new X server (ver. 1.5.x)
This is not specific to Russian. For Czech this is valid too, and I think this will influence all languages that need different keyboard layouts. This applies also to F10, and is preventing any reasonable use of any Java application, that needs input. I did not found any workaround..
Created attachment 324583 [details] screenshod showing the result with "non US" keyboard layout in Jedit
OK, I found a "workaround", that I do not understand how is related, but after starting SCIM the accented letters start to work in java apps.
There is increasing number of users complaining about this problem in F10. Increasing the priority and changing the version to F10.
(In reply to comment #2) > I have this bag too. Additional, if installed SUN JDK, this bug don`t > disappear. I think, this is trouble with new X server (ver. 1.5.x) I have the same problem in Fedora 10 and a Swedish keyboard and locale. Every character that needs to be typed using the ALT-GR modifier key fails to type correctly. The unmodified key is typed instead. E.g. if I want to type a '{' (typed as alt-gr 7) , I get a '7' typed instead. Just like in your case it affects the SUN JDK as well, so you are probably right that this is a Xorg problem.
If I run a Sun JDK on a Solaris 10 box, and display the on Fedora 10 box I get the same behavior.(on other displays it works fine). This strengthens my suspision that this is an X11 bug or at least something that should be investigated togehter with the Xorg peple.
It has something to do with SCIM/XIM. I'm not very familiar with the input methods and cannot give the full explanation. But for me works to set emtpy the value, before I've had XMODIFIES=@im=imsettings, i.e., set in the terminal export XMODIFIES= and than run jEdit. Similar problem has arised in Opera (v. 9.63, 10 alpha). Then I've set value QT_IM_MODULE=scim-bridge
Yep, this is not a problem of java, it also affects QT apps. As "workaround" for those that do not need a special input methods, it's fine to do yum remove scim* im-chooser* imsettings* m17n*
In view of comment #9 and #10, changing the component to SCIM
Tagoh-san, is this related to imsettings?
Does this happen on KDE? we don't use imsettings for XIM on KDE though.
Tk based applications seam to suffer from the same problem. At least did I have problems with xmaxima.
(In reply to comment #14) > Tk based applications seam to suffer from the same problem. At least did I have > problems with xmaxima. On which desktops?
(In reply to comment #15) > (In reply to comment #14) > > Tk based applications seam to suffer from the same problem. At least did I have > > problems with xmaxima. > > On which desktops? At least on Fedora 10 and Gnome.
*** This bug has been marked as a duplicate of bug 489611 ***