Description of problem: IS keyboard in kde applications is not working. Icelandic characters áéóú are not possible to input with keyboard in gnome. Version-Release number of selected component (if applicable): kdesdk-4.1.2-4.fc10.x86_64 How reproducible: always Steps to Reproduce: 1. log in use gnome and icelandc keyboard 2. start kate type á 3. Actual results: ´a Expected results: á Additional info: This works in FC9, and when selecting KDE session when login inn after setting keyboard in kde
This sounds like a regression from the new X11 keyboard input mechanism (it now uses the "evdev" driver instead of the "kbd" driver). But I have no idea if it's X11's, Qt's or kdelibs's fault. What appears to be happening is that something is enabling the nodeadkeys option somewhere.
*** Bug 468977 has been marked as a duplicate of this bug. ***
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle. Changing version to '10'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Same problem here, although it's in reverse : doesn't work in GNOME native applications in a GNOME environment but works in KDE applications in GNOME environment. How reproducible: always Steps to Reproduce: 1. log in use gnome and canadian multilingual keyboard 2. start gedit type á 3. Actual results: ´a Expected results: á 4. start kwrite type á Actual results: á Expected results: á
*** Bug 477552 has been marked as a duplicate of this bug. ***
Looks like this also affects Qt-only apps (see duplicate).
GTK+ applications have their own copy of the compose sequence table, so in a default GNOME environment (without SCIM, without setting the GTK_IM_MODULE variable), dead keys should work irrespective of other settings. Last time I checked for QT applications, they look up the XOrg compose table files, which are located at /usr/share/X11/locale, and the file chosen depends on your current locale. See the discussion at bug 477552 for some more hints. In my case (I have GNOME/Ubuntu 8.10/partial installation of QT apps), accents work. When I use 'strace' on a QT app, I get access("/usr/share/X11/locale/el_GR.UTF-8/Compose", R_OK) = 0 which shows that the compose file is read successfully for me.
I have not noticed this bug in Ubuntu 8.10. I tried strace for kwrite and gedit in GNOME and kwrite in KDE. Results from strace In gnome kwrite strace -Ff -tt kwrite 2>&1 | tee strace_kwrite.log [floki@flokip ~]$ cat strace_kwrite.log | grep /usr/share/X11/locale/ 00:15:12.406207 open("/usr/share/X11/locale/locale.alias", O_RDONLY) = 8 00:15:12.410857 open("/usr/share/X11/locale/locale.alias", O_RDONLY) = 8 00:15:12.414368 open("/usr/share/X11/locale/locale.dir", O_RDONLY) = 8 00:15:12.415913 access("/usr/share/X11/locale/en_US.UTF-8/XLC_LOCALE", R_OK) = 0 00:15:12.416026 open("/usr/share/X11/locale/en_US.UTF-8/XLC_LOCALE", O_RDONLY) = 8 In gnome gedit strace -Ff -tt gedit 2>&1 | tee strace_gedit.log [floki@flokip ~]$ cat strace_gedit.log | grep /usr/share/X11/locale/ 00:59:30.270400 open("/usr/share/X11/locale/locale.alias", O_RDONLY) = 3 00:59:30.272545 open("/usr/share/X11/locale/locale.alias", O_RDONLY) = 3 00:59:30.274101 open("/usr/share/X11/locale/locale.dir", O_RDONLY) = 3 00:59:30.275059 access("/usr/share/X11/locale/en_US.UTF-8/XLC_LOCALE", R_OK) = 0 00:59:30.275127 open("/usr/share/X11/locale/en_US.UTF-8/XLC_LOCALE", O_RDONLY) = 3 [floki@flokip ~]$ IN KDE kwrite strace -Ff -tt kwrite 2>&1 | tee strace_kwrite_kde.log cat strace_kwrite_kde.log | grep /usr/share/X11/locale/ [floki@flokip Documents]$ cat strace_kwrite_kde.log | grep /usr/share/X11/locale/ 01:14:32.454079 open("/usr/share/X11/locale/locale.alias", O_RDONLY) = 8 01:14:32.458167 open("/usr/share/X11/locale/locale.alias", O_RDONLY) = 8 01:14:32.460606 open("/usr/share/X11/locale/locale.dir", O_RDONLY) = 8 01:14:32.462096 access("/usr/share/X11/locale/en_US.UTF-8/XLC_LOCALE", R_OK) = 0 01:14:32.462207 open("/usr/share/X11/locale/en_US.UTF-8/XLC_LOCALE", O_RDONLY) = 8 01:14:33.382485 open("/usr/share/X11/locale/compose.dir", O_RDONLY) = 13 01:14:33.383453 access("/usr/share/X11/locale/en_US.UTF-8/Compose", R_OK) = 0 01:14:33.383608 stat("/usr/share/X11/locale/en_US.UTF-8/Compose", {st_mode=S_IFREG|0644, st_size=621145, ...}) = 0 01:14:33.383861 stat("/usr/share/X11/locale/en_US.UTF-8/Compose", {st_mode=S_IFREG|0644, st_size=621145, ...}) = 0 01:14:33.384025 open("/usr/share/X11/locale/en_US.UTF-8/Compose", O_RDONLY) = 13 01:14:33.487054 open("/usr/share/X11/locale/compose.dir", O_RDONLY) = 13 01:14:33.488016 access("/usr/share/X11/locale/en_US.UTF-8/Compose", R_OK) = 0 01:14:33.488171 stat("/usr/share/X11/locale/en_US.UTF-8/Compose", {st_mode=S_IFREG|0644, st_size=621145, ...}) = 0 01:14:33.488423 stat("/usr/share/X11/locale/en_US.UTF-8/Compose", {st_mode=S_IFREG|0644, st_size=621145, ...}) = 0 01:14:33.488588 open("/usr/share/X11/locale/en_US.UTF-8/Compose", O_RDONLY) = 13 [floki@flokip Documents]$
From strace log in F9 for kwrite [floki@flokif9 ~]$ cat strace_kwrite.log | grep /usr/share/X11/locale/ 02:02:32.627756 open("/usr/share/X11/locale/locale.alias", O_RDONLY) = 8 02:02:32.629755 open("/usr/share/X11/locale/locale.dir", O_RDONLY) = 8 02:02:32.630908 access("/usr/share/X11/locale/en_US.UTF-8/XLC_LOCALE", R_OK) = 0 02:02:32.630989 open("/usr/share/X11/locale/en_US.UTF-8/XLC_LOCALE", O_RDONLY) = 8 02:02:33.449190 open("/usr/share/X11/locale/compose.dir", O_RDONLY) = 13 02:02:33.450295 access("/usr/share/X11/locale/en_US.UTF-8/Compose", R_OK) = 0 02:02:33.450373 open("/usr/share/X11/locale/en_US.UTF-8/Compose", O_RDONLY) = 13 02:02:33.450816 open("/usr/share/X11/locale/compose.dir", O_RDONLY) = 13 02:02:33.451880 access("/usr/share/X11/locale/en_US.UTF-8/Compose", R_OK) = 0 02:02:33.452084 stat("/usr/share/X11/locale/en_US.UTF-8/Compose", {st_mode=S_IFREG|0644, st_size=621145, ...}) = 0 02:02:33.452374 stat("/usr/share/X11/locale/en_US.UTF-8/Compose", {st_mode=S_IFREG|0644, st_size=621145, ...}) = 0 02:02:33.452566 open("/usr/share/X11/locale/en_US.UTF-8/Compose", O_RDONLY) = 13 02:02:33.580216 open("/usr/share/X11/locale/compose.dir", O_RDONLY) = 13 02:02:33.581299 access("/usr/share/X11/locale/en_US.UTF-8/Compose", R_OK) = 0 02:02:33.581379 open("/usr/share/X11/locale/en_US.UTF-8/Compose", O_RDONLY) = 13 02:02:33.581732 open("/usr/share/X11/locale/compose.dir", O_RDONLY) = 13 02:02:33.582770 access("/usr/share/X11/locale/en_US.UTF-8/Compose", R_OK) = 0 02:02:33.582947 stat("/usr/share/X11/locale/en_US.UTF-8/Compose", {st_mode=S_IFREG|0644, st_size=621145, ...}) = 0 02:02:33.583235 stat("/usr/share/X11/locale/en_US.UTF-8/Compose", {st_mode=S_IFREG|0644, st_size=621145, ...}) = 0 02:02:33.583426 open("/usr/share/X11/locale/en_US.UTF-8/Compose", O_RDONLY) = 13 [floki@flokif9 ~]$ cat strace_kwrite.log | grep /usr/share/X11/locale/ 02:02:32.627756 open("/usr/share/X11/locale/locale.alias", O_RDONLY) = 8 02:02:32.629755 open("/usr/share/X11/locale/locale.dir", O_RDONLY) = 8 02:02:32.630908 access("/usr/share/X11/locale/en_US.UTF-8/XLC_LOCALE", R_OK) = 0 02:02:32.630989 open("/usr/share/X11/locale/en_US.UTF-8/XLC_LOCALE", O_RDONLY) = 8 02:02:33.449190 open("/usr/share/X11/locale/compose.dir", O_RDONLY) = 13 02:02:33.450295 access("/usr/share/X11/locale/en_US.UTF-8/Compose", R_OK) = 0 02:02:33.450373 open("/usr/share/X11/locale/en_US.UTF-8/Compose", O_RDONLY) = 13 02:02:33.450816 open("/usr/share/X11/locale/compose.dir", O_RDONLY) = 13 02:02:33.451880 access("/usr/share/X11/locale/en_US.UTF-8/Compose", R_OK) = 0 02:02:33.452084 stat("/usr/share/X11/locale/en_US.UTF-8/Compose", {st_mode=S_IFREG|0644, st_size=621145, ...}) = 0 02:02:33.452374 stat("/usr/share/X11/locale/en_US.UTF-8/Compose", {st_mode=S_IFREG|0644, st_size=621145, ...}) = 0 02:02:33.452566 open("/usr/share/X11/locale/en_US.UTF-8/Compose", O_RDONLY) = 13 02:02:33.580216 open("/usr/share/X11/locale/compose.dir", O_RDONLY) = 13 02:02:33.581299 access("/usr/share/X11/locale/en_US.UTF-8/Compose", R_OK) = 0 02:02:33.581379 open("/usr/share/X11/locale/en_US.UTF-8/Compose", O_RDONLY) = 13 02:02:33.581732 open("/usr/share/X11/locale/compose.dir", O_RDONLY) = 13 02:02:33.582770 access("/usr/share/X11/locale/en_US.UTF-8/Compose", R_OK) = 0 02:02:33.582947 stat("/usr/share/X11/locale/en_US.UTF-8/Compose", {st_mode=S_IFREG|0644, st_size=621145, ...}) = 0 02:02:33.583235 stat("/usr/share/X11/locale/en_US.UTF-8/Compose", {st_mode=S_IFREG|0644, st_size=621145, ...}) = 0 02:02:33.583426 open("/usr/share/X11/locale/en_US.UTF-8/Compose", O_RDONLY) = 13 [floki@flokif9 ~]$
Thanks Floki. It looks that the Compose file is being read properly and the problem should be something else. Another direction to investigate if the problem has to do with character encodings. A bug reported a few times with KDE apps in Ubuntu is that when you try the Open dialog box and attempt to open a filename with Unicode characters (non-ISO-8859-1), the program fails. I think it shows the characters as ??????? So, you can create a file with name ΑυτήΕίναιΜιαΔοκιμή.txt, then try to view/open it with the File/Open option. If you see ?????? characters instead of Unicode, and you have the deadkey issue, then it might be a more general problem. Apart from that, I cannot think of a possible problem. You would need to take it to the KDE and QT teams.
OK. I created file with name ΑυτήΕίναιΜιαΔοκιμή.txt. I can view/open and see the right file name. With KWrite ( started from GNOME ).
Thanks Floki for being prompt in testing these cases. Since it appears the issue is not about encodings, you can 1. check the Bugzilla databases for the QT and KDE project for similar reports 2. Go to the Freenode IRC network, and try to get hold of a KDE or QT developer, and ask for his/her insight on this report.
Thank you for the bug report. This issue needs to be addressed by the upstream developers. Please submit a report at http://bugs.kde.org. You are requested to add the bugzilla link here for tracking purposes. Please make sure the bug isn't already in the upstream bug tracker before filing it.
See https://bugs.kde.org/show_bug.cgi?id=180506
Thanks for reporting this upstream. Will monitor for resolution.
I'd feel better if it were cross upstreamed to both kde and gnome, as it may well be a in bug either, or a simple incompatibility.
(In reply to comment #16) > I'd feel better if it were cross upstreamed to both kde and gnome, as it may > well be a in bug either, or a simple incompatibility. I do not think it is a bug (even partial) in GNOME. The common case is that we try to use KDE/QT applications from a GNOME desktop, and most probably some services/libraries/settings that should be enabled, are not. To take it a bit further. If a typical Fedora KDE desktop works just fine with dead keys, then the KDE/QT people may well say that the problem is a packaging problem. That is, when you hand-pick and install a KDE/QT application, the package manager should (hypothetically) enable some system settings so that dead keys are not affected in QT applications. For this scenario, we would need first someone from KDE/QT to tell us what's the source of the bug. Thus, I think it was OK to change the bug to 'CLOSED UPSTREAM'.
*** Bug 481017 has been marked as a duplicate of this bug. ***
I had the same issue, and I just wanted to share that Simos' suggestion on Bug #477552 (#c7) solved the problem, ie starting for instance kile with : QT_IM_MODULE=xim kile NB : QT_IM_MODULE was set to 'scim' by myself before, I don't know what is its defauld value.
Upstream report from SCIM, https://sourceforge.net/tracker2/?func=detail&atid=650539&aid=1668290&group_id=108454
All relevant bugs are closed one way or another, but the bug is still here. In my humble opinion it is a configuration bug, because in LyX in fedora 10 it does it when I use a regular user account, but not as ROOT! If I login as root from a gnome terminal window of another user and run LyX and type ;a with a greek layout, I get ά, if I do it as a regural user, I get 'α. Please fix it, because it "kills" me, I advise ppl to use fedora 9 that doesn't have it.
Did you try the trick of comment #19 ?
yes, it doesn't work either for kile or lyx I also did: strace -Ff -tt lyx 2>&1|tee > lyx_strace.log as root strace -Ff -tt lyx 2>&1|tee > lyx_strace.log as wordprocess (my user) At this point I clicked to make the window active, pressed ctrl-n to open a new file, switched to greek and pressed ;a which for root gave ά and for wordprocess gave ´α and after that quit the program. diff lyx_strace.log /home/wordprocess/lyx_strace.log|grep /usr/share/X11/locale/ and it returned: diff lyx_strace.log /home/wordprocess/lyx_strace.log|grep /usr/share/X11/locale/ < 22:52:01.986230 open("/usr/share/X11/locale/locale.alias", O_RDONLY) = 10 < 22:52:01.988477 open("/usr/share/X11/locale/locale.alias", O_RDONLY) = 10 < 22:52:01.989695 open("/usr/share/X11/locale/locale.dir", O_RDONLY) = 10 < 22:52:01.990643 access("/usr/share/X11/locale/en_US.UTF-8/XLC_LOCALE", R_OK) = 0 < 22:52:01.990709 open("/usr/share/X11/locale/en_US.UTF-8/XLC_LOCALE", O_RDONLY) = 10 > 22:52:48.507434 open("/usr/share/X11/locale/locale.alias", O_RDONLY) = 10 > 22:52:48.509398 open("/usr/share/X11/locale/locale.alias", O_RDONLY) = 10 > 22:52:48.510633 open("/usr/share/X11/locale/locale.dir", O_RDONLY) = 10 > 22:52:48.511463 access("/usr/share/X11/locale/en_US.UTF-8/XLC_LOCALE", R_OK) = 0 > 22:52:48.511527 open("/usr/share/X11/locale/en_US.UTF-8/XLC_LOCALE", O_RDONLY) = 10 which I guess means that both users do the same things as far as X11 are concerned.
also: diff lyx_strace.log /home/wordprocess/lyx_strace.log|grep /usr/lib64/qt < stat("/usr/lib64/qt-3.3/bin/lyx", 0x2e17368) = -1 ENOENT (No such file or directory) < lstat("/usr/lib64/qt-3.3/bin/lyx", 0x7fffec5f33f0) = -1 ENOENT (No such file or directory) < stat("/usr/lib64/qt-3.3/bin/lyx", 0x2e17368) = -1 ENOENT (No such file or directory) < lstat("/usr/lib64/qt-3.3/bin/lyx", 0x7fffec5f3430) = -1 ENOENT (No such file or directory) > stat("/usr/lib64/qt-3.3/bin/lyx", 0x182b458) = -1 ENOENT (No such file or directory) > lstat("/usr/lib64/qt-3.3/bin/lyx", 0x7fffd8d88850) = -1 ENOENT (No such file or directory) > stat("/usr/lib64/qt-3.3/bin/lyx", 0x182b458) = -1 ENOENT (No such file or directory) > lstat("/usr/lib64/qt-3.3/bin/lyx", 0x7fffd8d88890) = -1 ENOENT (No such file or directory) < statfs("/usr/lib64/qt4/plugins/inputmethods", {f_type="EXT2_SUPER_MAGIC", f_bsize=4096, f_blocks=12901366, f_bfree=11189442, f_bavail=10534091, f_files=3276800, f_ffree=3033685, f_fsid={682310117, -1813623468}, f_namelen=255, f_frsize=4096}) = 0 > statfs("/usr/lib64/qt4/plugins/inputmethods", {f_type="EXT2_SUPER_MAGIC", f_bsize=4096, f_blocks=12901366, f_bfree=11189345, f_bavail=10533994, f_files=3276800, f_ffree=3033686, f_fsid={682310117, -1813623468}, f_namelen=255, f_frsize=4096}) = 0 < statfs("/usr/lib64/qt4/plugins/styles", {f_type="EXT2_SUPER_MAGIC", f_bsize=4096, f_blocks=12901366, f_bfree=11189441, f_bavail=10534090, f_files=3276800, f_ffree=3033685, f_fsid={682310117, -1813623468}, f_namelen=255, f_frsize=4096}) = 0 > statfs("/usr/lib64/qt4/plugins/styles", {f_type="EXT2_SUPER_MAGIC", f_bsize=4096, f_blocks=12901366, f_bfree=11189345, f_bavail=10533994, f_files=3276800, f_ffree=3033686, f_fsid={682310117, -1813623468}, f_namelen=255, f_frsize=4096}) = 0 < open("/usr/lib64/qt4/plugins/imageformats", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 10 < statfs("/usr/lib64/qt4/plugins/imageformats", {f_type="EXT2_SUPER_MAGIC", f_bsize=4096, f_blocks=12901366, f_bfree=11189439, f_bavail=10534088, f_files=3276800, f_ffree=3033685, f_fsid={682310117, -1813623468}, f_namelen=255, f_frsize=4096}) = 0 > open("/usr/lib64/qt4/plugins/imageformats", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 11 > statfs("/usr/lib64/qt4/plugins/imageformats", {f_type="EXT2_SUPER_MAGIC", f_bsize=4096, f_blocks=12901366, f_bfree=11189345, f_bavail=10533994, f_files=3276800, f_ffree=3033686, f_fsid={682310117, -1813623468}, f_namelen=255, f_frsize=4096}) = 0 < open("/usr/lib64/qt4/plugins/imageformats/libqgif.so", O_RDONLY) = 10 < open("/usr/lib64/qt4/plugins/imageformats/libqico.so", O_RDONLY) = 10 < open("/usr/lib64/qt4/plugins/imageformats/libqjpeg.so", O_RDONLY) = 10 > open("/usr/lib64/qt4/plugins/imageformats/libqgif.so", O_RDONLY) = 11 > open("/usr/lib64/qt4/plugins/imageformats/libqico.so", O_RDONLY) = 11 > open("/usr/lib64/qt4/plugins/imageformats/libqjpeg.so", O_RDONLY) = 11 < open("/usr/lib64/qt4/plugins/imageformats/libqmng.so", O_RDONLY) = 10 > open("/usr/lib64/qt4/plugins/imageformats/libqmng.so", O_RDONLY) = 11 < open("/usr/lib64/qt4/plugins/imageformats/libqsvg.so", O_RDONLY) = 10 < open("/usr/lib64/qt4/plugins/imageformats/libqtiff.so", O_RDONLY) = 10 > open("/usr/lib64/qt4/plugins/imageformats/libqsvg.so", O_RDONLY) = 11 > open("/usr/lib64/qt4/plugins/imageformats/libqtiff.so", O_RDONLY) = 11
*** Bug 490841 has been marked as a duplicate of this bug. ***
Fedora 10 - i386 Icelandic keyboard. I'm having the same problem. If I start kwrite while running gnome I can't type á é í for example (all I get is 'a 'e 'i) but when I start kwrite like this: sudo su - myusername -c kwrite Lo and behold... I have accented keys! Why it works is a mystery to me but it does.. Could it be some sort of a configuration error that needs to be addressed in Fedora rather than a KDE/QT bug?
This bug is still here, even in Fedora 11. Deadkeys will work with Qt apps only if they are running with root access.
*** Bug 501542 has been marked as a duplicate of this bug. ***
Any update? At KDE bugzilla they said it's fixed in F11, but that's not true. SCIM Works with some tweaking but dead keys don't。
F11 uses I-Bus by default, not SCIM.
IBUS is immature, so I installed SCIM.
The one who tested upstream most likely tested with the defaults, i.e. with SCIM on F10 and with I-Bus on F11, that'd explain the difference.
(In reply to comment #27) > This bug is still here, even in Fedora 11. > Deadkeys will work with Qt apps only if they are running with root access. This is definitely a permission problem: when run as a regular user, dead keys fail in every single Qt application I have installed, whether they depend on qt 4.5.1 or 3.3.8b. Then I try to run them as root, and dead keys suddenly work in every one of them! Warning: after running some of these Qt applications as root I could not log into X anymore. At least not until I deleted some now root-owned .ICEauthority* files from my home directory. Tests performed from the XFCE desktop of F10. I had no problem with F9. I am available for more testing (provided I can easily revert any side-effect this would have).
(In reply to comment #33) > This is definitely a permission problem > [...] > Tests performed from the XFCE desktop of F10. I had no problem with F9. Sorry for the noise: forgot to say that I stripped my system of every scim-* package available. To no effect. I also tried the QT_IM_MODULE=xim workaround, to no effect.
(In reply to comment #26) > If I start kwrite while running gnome I can't type á é í for example (all I get > is 'a 'e 'i) Not exactly. - uk keyboard (i.e., no dead keys) 'a 'e 'i - international keyboard as user: ´a ´e ´i - international keyboard as root: á é í
Any updates on this? All say it's fixed and the bugs Cloased but still, with SCIM installed, nothing works. Anyone reported that to SCIM's bugzilla?
(In reply to comment #36) > Any updates on this? > All say it's fixed and the bugs Cloased but still, with SCIM installed, nothing > works. For what I can say, it still does not work for me either with QT_IM_MODULE set to scim-bridge. > Anyone reported that to SCIM's bugzilla? Strangely, I can't find any relevant topic on it : http://sourceforge.net/tracker/?group_id=108454&atid=650539 Please feel free to file a report, preferably linking to some of the many old bug reports like this one. (I could file it but it takes time to make a good report, and I don't have time now.)
>Please feel free to file a report For some reason I can't login on SF. I tried to signup for a new account but I can't activate it. I'll try again...