I used Gnome for a long time, but preferred vanilla X input method (xim) over the default GTK behaviour. I just set GTK_IM_MODULE and QT_IM_MODULE environment variables to xim, and didn't have any problem with multiple-layout config, Compose key, custom ~/.XCompose and misc:typo typography extensions.

Recent Gnome 3.6 completely screwed keyboard input by shipping a half-baked and buggy ibus and forcing it upon the users. I just couldn't get the keyboard working as well as before (even with ibus disabled), and had to abandon Gnome completely.

Now I use a simple window manager, and configure my keyboard with setxkbmap. While the keyboard works well again, I couldn't get the Compose key working everywhere. Compose works in plain X11 apps (xterm), but it doesn't work in neither GTK2, nor GTK3, nor Qt apps.

I use current Archlinux versions:

xorg-xinput 1.6.0
xorg-server 1.13.1
xf86-input-keyboard 1.6.2
gtk2 2.24.14
gtk3 3.6.4
qt 4.8.4

and enable Compose key like this:

setxkbmap ... -option 'compose:menu'

and export GTK_IM_MODULE, QT_IM_MODULE variables:

xim xim

Compose key is properly recognized by X11:

$ xev | grep -A2 --line-buffered '^KeyRelease' | sed -n '/keycode /s/^.*keycode \([0-9]*\).* (.*, \(.*\)).*$/\1 \2/p'
135 Multi_key

It works properly in xterm, sequences from my ~/.XCompose included. It doesn't work in either GTK or Qt apps. Let say, if I enter Compose ', then apps echo ' immediately, without waiting for the third key in the sequence.

Now I suppose something has changed in either Xorg (because Compose doesn't work in Qt apps either), or in GTK and Qt. *_IM_MODULE variables are not enough now. What else is required to make modern GTK and Qt recognise xim and its Compose sequences?

P.S. There is a similar (and unanswered) question about Compose key not working in GTK. Unlike the asker, I don't have ibus installed.


Found a solution which works for GTK apps (but not Qt). One needs to set


to let X11 handle dead keys. Thanks to @PabloSaratxaga for his answer.

| improve this answer | |

I had a similar problem in openSUSE. ~/.XCompose would be ignored by GTK+ applications, so my own Compose sequences did not work in Firefox, Gimp, and others.

I found out that gtk-query-immodules-2.0 listed a few input methods, but not xim; so, irrespective of the GTK_IM_MODULE variable, xim was unavailable. Installing the packages gtk2-immodule-xim (and friends) solved the problem.

Maybe this remark proves useful for people suffering from the same curse.

| improve this answer | |

This is a way of persistent configuration. It is described for example here https://wiki.edubuntu.org/ComposeKey#line-66 . I configured compose keys with ~/.XCompose this way. I have checked this both on ubuntu and debian systems.

| improve this answer | |
  • The problem is that even the one-off method has stopped working. Instructions for persistent change are Debian/Ubuntu specific. – sastanin Jan 15 '13 at 11:03

For when it worked in GTK programmes, but not QT programmes, which is what I had, I found the solution here:

GTK+ apps use their own copy of the Compose file from Xorg. The vast majority of compose sequences should continue to work, with a few legacy exceptions. xterm and QT apps use the XOrg compose sequences which is the en_US.UTF-8 file in /usr/share/X11/locate and the ~/.XCompose file if it exists.

Which meant for me:

ln -s /usr/share/X11/locale/en_US.UTF-8/Compose ~/.XCompose

and then it worked in QT programmes, too.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.