Compose key not working in Qt apps in Gnome
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Fedora |
Won't Fix
|
Medium
|
|||
qt4-x11 (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
I'm unable to input accentuated characters in any Qt app in Gnome environment.
Compose + ` + e produces `e instead of è.
I'm using IBUS as input method, here is my env variables:
QT_IM_MODULE=xim
GTK_IM_MODULE=ibus
XMODIFIERS=@im=ibus
LANG=en_US.UTF-8
Compose key works fine in the same applications when run as root with sudo.
In Red Hat Bugzilla #468590, Kevin (kevin-redhat-bugs) wrote : | #5 |
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.
In Red Hat Bugzilla #468590, Kevin (kevin-redhat-bugs) wrote : | #6 |
*** Bug 468977 has been marked as a duplicate of this bug. ***
In Red Hat Bugzilla #468590, Bug (bug-redhat-bugs) wrote : | #7 |
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://
In Red Hat Bugzilla #468590, Louis-Philippe (louis-philippe-redhat-bugs) wrote : | #8 |
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:
á
In Red Hat Bugzilla #468590, Kevin (kevin-redhat-bugs) wrote : | #9 |
*** Bug 477552 has been marked as a duplicate of this bug. ***
In Red Hat Bugzilla #468590, Kevin (kevin-redhat-bugs) wrote : | #10 |
Looks like this also affects Qt-only apps (see duplicate).
In Red Hat Bugzilla #468590, Simos (simos-redhat-bugs) wrote : | #11 |
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/
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(
which shows that the compose file is read successfully for me.
In Red Hat Bugzilla #468590, Flóki (flki-redhat-bugs) wrote : | #12 |
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/
00:15:12.406207 open("/
00:15:12.410857 open("/
00:15:12.414368 open("/
00:15:12.415913 access(
00:15:12.416026 open("/
In gnome gedit
strace -Ff -tt gedit 2>&1 | tee strace_gedit.log
[floki@flokip ~]$ cat strace_gedit.log | grep /usr/share/
00:59:30.270400 open("/
00:59:30.272545 open("/
00:59:30.274101 open("/
00:59:30.275059 access(
00:59:30.275127 open("/
[floki@flokip ~]$
IN KDE kwrite
strace -Ff -tt kwrite 2>&1 | tee strace_
cat strace_
[floki@flokip Documents]$ cat strace_
01:14:32.454079 open("/
01:14:32.458167 open("/
01:14:32.460606 open("/
01:14:32.462096 access(
01:14:32.462207 open("/
01:14:33.382485 open("/
01:14:33.383453 access(
01:14:33.383608 stat("/
01:14:33.383861 stat("/
01:14:33.384025 open("/
01:14:33.487054 open("/
01:14:33.488016 access(
01:14:33.488171 stat("/
01:14:33.488423 stat("/
01:14:33.488588 open("/
[floki@flokip Documents]$
In Red Hat Bugzilla #468590, Flóki (flki-redhat-bugs) wrote : | #13 |
From strace log in F9 for kwrite
[floki@flokif9 ~]$ cat strace_kwrite.log | grep /usr/share/
02:02:32.627756 open("/
02:02:32.629755 open("/
02:02:32.630908 access(
02:02:32.630989 open("/
02:02:33.449190 open("/
02:02:33.450295 access(
02:02:33.450373 open("/
02:02:33.450816 open("/
02:02:33.451880 access(
02:02:33.452084 stat("/
02:02:33.452374 stat("/
02:02:33.452566 open("/
02:02:33.580216 open("/
02:02:33.581299 access(
02:02:33.581379 open("/
02:02:33.581732 open("/
02:02:33.582770 access(
02:02:33.582947 stat("/
02:02:33.583235 stat("/
02:02:33.583426 open("/
[floki@flokif9 ~]$ cat strace_kwrite.log | grep /usr/share/
02:02:32.627756 open("/
02:02:32.629755 open("/
02:02:32.630908 access(
02:02:32.630989 open("/
02:02:33.449190 open("/
02:02:33.450295 access(
02:02:33.450373 open("/
02:02:33.450816 open("/
02:02:33.451880 access(
02:02:33.452084 stat("/
02:02:33.452374 stat("/
02:02:33.452566 open("/
02:02:33.580216 open("/
02:02:33.581299 access(
02:02:33.581379 open("/
02:02:33.581732 open("/
02:02:33.582770 acce...
In Red Hat Bugzilla #468590, Simos (simos-redhat-bugs) wrote : | #14 |
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 ΑυτήΕίναιΜιαΔοκ
Apart from that, I cannot think of a possible problem. You would need to take it to the KDE and QT teams.
In Red Hat Bugzilla #468590, Flóki (flki-redhat-bugs) wrote : | #15 |
OK. I created file with name ΑυτήΕίναιΜιαΔοκ
I can view/open and see the right file name.
With KWrite ( started from GNOME ).
In Red Hat Bugzilla #468590, Simos (simos-redhat-bugs) wrote : | #16 |
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.
In Red Hat Bugzilla #468590, Steven (steven-redhat-bugs) wrote : | #17 |
Thank you for the bug report. This issue needs to be addressed by the upstream developers. Please submit a report at http://
In Red Hat Bugzilla #468590, Flóki (flki-redhat-bugs) wrote : | #18 |
In Red Hat Bugzilla #468590, Steven (steven-redhat-bugs) wrote : | #19 |
Thanks for reporting this upstream. Will monitor for resolution.
In Red Hat Bugzilla #468590, Rex (rex-redhat-bugs) wrote : | #20 |
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 Red Hat Bugzilla #468590, Simos (simos-redhat-bugs) wrote : | #21 |
(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/
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'.
In Red Hat Bugzilla #468590, Kevin (kevin-redhat-bugs) wrote : | #22 |
*** Bug 481017 has been marked as a duplicate of this bug. ***
In Red Hat Bugzilla #468590, Skippy (skippy-redhat-bugs) wrote : | #23 |
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.
In Red Hat Bugzilla #468590, Simos (simos-redhat-bugs) wrote : | #24 |
Upstream report from SCIM,
https:/
In Red Hat Bugzilla #468590, George (george-redhat-bugs) wrote : | #25 |
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.
In Red Hat Bugzilla #468590, Skippy (skippy-redhat-bugs) wrote : | #26 |
Did you try the trick of comment #19 ?
In Red Hat Bugzilla #468590, George (george-redhat-bugs) wrote : | #27 |
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/wordproce
and it returned:
diff lyx_strace.log /home/wordproce
< 22:52:01.986230 open("/
< 22:52:01.988477 open("/
< 22:52:01.989695 open("/
< 22:52:01.990643 access(
< 22:52:01.990709 open("/
> 22:52:48.507434 open("/
> 22:52:48.509398 open("/
> 22:52:48.510633 open("/
> 22:52:48.511463 access(
> 22:52:48.511527 open("/
which I guess means that both users do the same things as far as X11 are concerned.
In Red Hat Bugzilla #468590, George (george-redhat-bugs) wrote : | #28 |
also:
diff lyx_strace.log /home/wordproce
< stat("/
< lstat("
< stat("/
< lstat("
> stat("/
> lstat("
> stat("/
> lstat("
< statfs(
> statfs(
< statfs(
> statfs(
< open("/
< statfs(
> open("/
> statfs(
< open("/
< open("/
< open("/
> open("/
> open("/
> open("/
< open("/
> open("/
< open("/
< open("/
> open("/usr/li...
In Red Hat Bugzilla #468590, Kevin (kevin-redhat-bugs) wrote : | #29 |
*** Bug 490841 has been marked as a duplicate of this bug. ***
In Red Hat Bugzilla #468590, Sigurður (sigurur-redhat-bugs) wrote : | #30 |
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?
In Red Hat Bugzilla #468590, DemetrisK (demetrisk-redhat-bugs) wrote : | #31 |
This bug is still here, even in Fedora 11.
Deadkeys will work with Qt apps only if they are running with root access.
In Red Hat Bugzilla #468590, Kevin (kevin-redhat-bugs) wrote : | #32 |
*** Bug 501542 has been marked as a duplicate of this bug. ***
In Red Hat Bugzilla #468590, DemetrisK (demetrisk-redhat-bugs) wrote : | #33 |
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。
In Red Hat Bugzilla #468590, Kevin (kevin-redhat-bugs) wrote : | #34 |
F11 uses I-Bus by default, not SCIM.
In Red Hat Bugzilla #468590, DemetrisK (demetrisk-redhat-bugs) wrote : | #35 |
IBUS is immature, so I installed SCIM.
In Red Hat Bugzilla #468590, Kevin (kevin-redhat-bugs) wrote : | #36 |
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 Red Hat Bugzilla #468590, MarcH (march-redhat-bugs) wrote : | #37 |
(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 Red Hat Bugzilla #468590, MarcH (march-redhat-bugs) wrote : | #38 |
(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 Red Hat Bugzilla #468590, MarcH (march-redhat-bugs) wrote : | #39 |
(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: á é í
In Red Hat Bugzilla #468590, DemetrisK (demetrisk-redhat-bugs) wrote : | #40 |
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 Red Hat Bugzilla #468590, Skippy (skippy-redhat-bugs) wrote : | #41 |
(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://
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.)
In Red Hat Bugzilla #468590, DemetrisK (demetrisk-redhat-bugs) wrote : | #42 |
>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...
Changed in fedora: | |
status: | Unknown → Fix Released |
Martin André (mandre) wrote : | #1 |
Using ibus-qt4, this bug should be fixed. But ibus-qt4 is broken too in karmic (see bug #481612) making it impossible to enter accentuated characters in Qt apps.
Jonathan Thomas (echidnaman) wrote : | #2 |
Fixed in Kubuntu 10.04.
Changed in qt4-x11 (Ubuntu): | |
status: | New → Fix Released |
Jonathan Thomas (echidnaman) wrote : | #3 |
Erm, that was meant for 481612, but this is fixed in 10.04 by default usage of IBus.
Changed in fedora: | |
importance: | Unknown → Medium |
status: | Fix Released → Won't Fix |
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): 4.1.2-4. fc10.x86_ 64
kdesdk-
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