After I did a complete update with `pacman` and rebooting, firefox and libreoffice aren't using my .XCompose anymore. I've been using it for years now. More information below.
$ uname -a Linux mnes 3.8.6-1-ARCH #1 SMP PREEMPT Sat Apr 6 07:27:01 CEST 2013 x86_64 GNU/Linux $ pacman -Qs xorg-server local/xorg-server 1.13.3-1 (xorg) Xorg X server $ pacman -Qs awesome local/awesome 3.5.1-1 Highly configurable framework window manager $ pacman -Qs firefox local/firefox 20.0.1-1 Standalone web browser from mozilla.org $ pacman -Qs libreoffice-common local/libreoffice-common 4.0.2-2 (libreoffice) common files for LibreOffice - a productivity suite that is compatible with other major office suites $ env | grep IM_ QT_IM_MODULE=xim GTK_IM_MODULE=xim
The funny thing is that when I call `gedit`, for instance, it reads the file, and behaves as it should.
$ strace -e open gedit |& grep Compose open("/usr/share/X11/locale/en_US.UTF-8/Compose", O_RDONLY) = 13 open("/home/edgard/.XCompose", O_RDONLY) = 13
But firefox and libreoffice don't read it, even if I try something like
export QT_IM_MODULE=xim & export GTK_IM_MODULE=xim ; libreoffice
I've created a minimal ~/.XCompose to test this:
# Import default rules from the system Compose file: include "/usr/share/X11/locale/en_US.UTF-8/Compose" <dead_acute> <p> : "þ"
So when I press <´> and then <p>, a thorn <þ> should appear. Indeed it is what happen in `xev`:
KeyPress event, serial 30, synthetic NO, window 0xe00001, root 0xbf, subw 0x0, time 2798854, (576,661), root:(577,692), state 0x0, keycode 34 (keysym 0xfe51, dead_acute), same_screen YES, XLookupString gives 2 bytes: (c2 b4) "´" XmbLookupString gives 0 bytes: XFilterEvent returns: True KeyRelease event, serial 33, synthetic NO, window 0xe00001, root 0xbf, subw 0x0, time 2798924, (576,661), root:(577,692), state 0x0, keycode 34 (keysym 0xfe51, dead_acute), same_screen YES, XLookupString gives 2 bytes: (c2 b4) "´" XFilterEvent returns: False KeyPress event, serial 33, synthetic NO, window 0xe00001, root 0xbf, subw 0x0, time 2799602, (576,661), root:(577,692), state 0x0, keycode 33 (keysym 0x70, p), same_screen YES, XLookupString gives 1 bytes: (70) "p" XmbLookupString gives 1 bytes: (70) "p" XFilterEvent returns: True [b]KeyPress event, serial 33, synthetic NO, window 0xe00001, root 0xbf, subw 0x0, time 2799602, (576,661), root:(577,692), state 0x0, keycode 0 (keysym 0x0, NoSymbol), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 2 bytes: (c3 be) "þ" XFilterEvent returns: False[/b] KeyRelease event, serial 33, synthetic NO, window 0xe00001, root 0xbf, subw 0x0, time 2799640, (576,661), root:(577,692), state 0x0, keycode 33 (keysym 0x70, p), same_screen YES, XLookupString gives 1 bytes: (70) "p" XFilterEvent returns: False
I have no idea where the problem might be. The _IM_ variables are already set on .bashrc and listed by `env`, the file is read by some programs and works in them, but not on Firefox nor in Libreoffice; and just in them, as far as I know. I hope I'm not missing anything elementary here ; )).
Last edited by Parjanya (2013-04-12 01:39:37)
Please use code tags as opposed to quote tags. Please edit your post.
There's no such thing as a stupid question, but there sure are a lot of inquisitive idiots !
Hey men, Iḿ (look at the "ḿ"), I'm having the SAME PROBLEM!!!
I had changed my "/usr/share/X11/locale/en_US.UTF-8/Compose" to make cedilla "ç" work as it should (here in Brasil), then I added those 2 vars at "/etc/environment":
Everything was working fine, in EVERY program... I'm Using: "Kali Linux" (it's basically "Debian Wheezy", I think 99% the same), with KDE
Then, I don't know if this is the reason, I attempted to rebuild and reinstall GTK with some changes, maybe it was that... don't know...
The problem here is the same, Firefox, Libreoffice, and maybe another 1 or 2 programs aren't respecting the environment variables.....
THE STRANGEST THING: (maybe this will help you solve this), when I use "KWrite" (like gedit, but for KDE), it workst almost 100%, even proved by your trick:
strace -e open kwrite |& grep Compose
But THEN: the first time (only the FIRST TIME) I use the "FIND" searchbox tool, (to find some text), IT'S THE SAME AS FIREFOX AND LIBREOFFICE, then, I close it, and hit: "Ctrl + F" again, AND IT'S NORMAL AGAIN???
the only thing I did different was rebuilding GTK2.0 with some changes, install, give up, reinstall the default(original) again... (after I realized that KDE uses QT instead of GTK... heheheh)
please help me!! I'm a fu..ing brazilian, I use "Ç" and single quotes ''''' all the time... i'm going MENTAL!!!!
Hah, that is a coincidence. I'm brazilian too. I'm sorry for the delay in answering you, I was waiting to update my system, so then perhaps the problem would vanish by itself; I've been that lucky before, but not at this time.
It seems our problem is very peculiar, as few people mess with the X input. Anyway, I've solved it:
The problem is GTK related. I cannot hope to understand (right now) how exactly it works, but I've discovered that the program `gtk-query-immodules-2.0` generates a list of IM (input methods) for the programs using the GTK libraries, and curiously enough that file was blank here. So everything I had to do was:
#gtk-query-immodules-2.0 > /etc/gtk-2.0/gtk.immodules
so that the program would fill that list, and behold, it works now. I've not rebooted, but I guess it will have to be done every boot, and that it should be done by itself, and it is not, for some reason.
There are other programs that generate that list for other GTK versions: `gtk-query-immodules-2.0-32` for the 32bit libraries, of which the file is in `/etc/gtk-2.0/gtk.immodules-32`. This one was already populated. There is also a `gtk-query-immodules-3.0` for the version 3, but I couldn't find where its file is, should be in `/etc/gtk-3.0/` somewhere, but it is not.
Since you are using another distro, this problem seems to be broader than a simple distro hiccup.
Hey man, sorry about my delay to awnswer too... I was finishing a relationship, very depressed, and sad... heafhuahehehe (really)...
Then I tryied everything you said (here the paths were a little different), but nothing worked...
I think it's a different Distro's problem indeed...
Also, I messed up a bit, maybe it was my fault...
But now I gave up! heheh, I got used to another shortcut... and moved on!!!
Good luck with future problems!!!