Description of problem: No matter what I try, I just can't get GTK_IM_MODULE and QT_IM_MODULE set correctly. It seems like /etc/X11/xinit/xinitrc.d/50-xinput.sh always results in empty GTK_IM_MODULE and QT_IM_MODULE set to ibus. I'm trying to get cedilla to work as ' + c/C to output ç and Ç ( as it's always been since old DOS times ) instead of ć and Ć The first step was to edit /usr/share/X11/locale/en_US.UTF-8/Compose and sed ć and Ć into ç and Ç ( not sure if this is really necessary ) If I open a Terminal and manually set GTK_IM_MODULE=cedilla and QT_IM_MODULE=xim , both GTK and QT programs work as I expect. Version-Release number of selected component (if applicable): imsettings-1.7.1-1.fc24.x86_64 How reproducible: Always Steps to Reproduce: 1. Choose any input method other than ibus ( via im-chooser ), logout, login. 2. Open Terminal and check if GTK_IM_MODULE and QT_IM_MODULE are set as expected 3. Actual results: GTK_IM_MODULE is not set and QT_IM_MODULE is always set to ibus Expected results: GTK_IM_MODULE and QT_IM_MODULE set as expected by the xinput files Additional info: I've managed to temporarily get GTK_IM_MODULES set by adding a file named /etc/X11/xinit/xinitrc.d/99-force-im.sh with the lines: #!/bin/bash export GTK_IM_MODULE=cedilla export QT_IM_MODULE=xim That's the only way I can get GTK programs to work with c cedil. But QT_IM_MODULE still gets overriden at logon.
BTW, ibus loads /usr/share/X11/locale/$LANG/Compose so if you run "env LC_CTYPE=el_GR.UTF-8 ibus-daemon --xim &", loads the compose file and also ibus loads $HOME/.config/ibus/Compose or $HOME/.XCompose for the customization. Which desktop do you use? If you use GNOME, you cannot use im-chooser to change the input method framework.
(In reply to fujiwara from comment #1) > Which desktop do you use? > If you use GNOME, you cannot use im-chooser to change the input method > framework. Hmm, yeah, that's right. and it was supposed to warn if it is and exit after that. but seems not at this moment. it is an another bug in im-chooser, but anyway.
(In reply to fujiwara from comment #1) > BTW, ibus loads /usr/share/X11/locale/$LANG/Compose so if you run "env > LC_CTYPE=el_GR.UTF-8 ibus-daemon --xim &", loads the compose file and also > ibus loads $HOME/.config/ibus/Compose or $HOME/.XCompose for the > customization. > > Which desktop do you use? > If you use GNOME, you cannot use im-chooser to change the input method > framework. I think I've touched a multiple bug :) Yes, I use GNOME ( I've always been kind of KDE/Plasma, but it got really buggy and I got used to and switched to GNOME in Fedora22 ). First, I had no idea of the "$HOME/.config/ibus/Compose" file usage. After copying ( I could have made a link ), QT worked! Then, I got back to my "/etc/X11/xinit/xinitrc.d/99-force-im.sh" and changed it to: #!/bin/bash export GTK_IM_MODULE=ibus Changed xinputrc alternative to point back to ibus, and changed im-chooser to ibus. All working fine now except for gnome-terminal. If I copy/past ç into gnome-terminal, it displays correctly, but trying to get ç via '+c still results in ć. About LC_CTYPE: My system is set to en_US and formats to Brasil ( GNOME settings ) The output from "env | grep LC" is : LC_PAPER=pt_BR.UTF-8 LC_MONETARY=pt_BR.UTF-8 LC_NUMERIC=pt_BR.UTF-8 LC_MEASUREMENT=pt_BR.UTF-8 LC_TIME=pt_BR.UTF-8 And the output of "locale" command is: LANG=en_US.UTF-8 LC_CTYPE="en_US.UTF-8" LC_NUMERIC=pt_BR.UTF-8 LC_TIME=pt_BR.UTF-8 LC_COLLATE="en_US.UTF-8" LC_MONETARY=pt_BR.UTF-8 LC_MESSAGES="en_US.UTF-8" LC_PAPER=pt_BR.UTF-8 LC_NAME="en_US.UTF-8" LC_ADDRESS="en_US.UTF-8" LC_TELEPHONE="en_US.UTF-8" LC_MEASUREMENT=pt_BR.UTF-8 LC_IDENTIFICATION="en_US.UTF-8" LC_ALL= Should LC_CTYPE have been set to pt_BR.UTF-8 ? I'll try two other setups: 1.) clear im-chooser settings, remove "/etc/X11/xinit/xinitrc.d/99-force-im.sh" to check if GTK_IM_MODULE gets set 2.) Try to setup LC_CTYPE=pt_BR.UTF-8 by editing /etc/locale.conf and remove the $HOME/.config/ibus/Compose to check if it works.
Updating: 1.) Cleared im-chooser settings, removed "/etc/X11/xinit/xinitrc.d/99-force-im.sh" - result: GTK_IM_MODULE is not set Restored "/etc/X11/xinit/xinitrc.d/99-force-im.sh" 2.) Removed "$HOME/.config/ibus/Compose", system reboot - result: It got back to typing ć as expected ( ibus had the ç Compose cached ) 3.) edited /etc/locale.conf and added LC_CTYPE=pt_BR.UTF-8, logged out and in - result: nothing changed system rebooted : Wotking as expected, now '+c is ç , even gnome-terminal worked! 4.) Now that setting LC_CTYPE fixed everything, I removed "/etc/X11/xinit/xinitrc.d/99-force-im.sh", rebooted - result: as expected, GTK_IM_MODULE is not set BUT everything is working fine with ç Ç My educated guess is that the "real" bug here is at GNOME settings... It seems like it ignores setting LC_CTYPE when you select "Formats" of another country. Simply setting LC_CTYPE solved all the input method problems... Should I open a new bug for the gnome-settings package?
From the quote from glibc docs (https://www.gnu.org/savannah-checkouts/gnu/libc/manual/html_node/Locale-Categories.html): LC_CTYPE This category applies to classification and conversion of characters, and to multibyte and wide characters; see Character Handling, and Character Set Handling. So it isn't about the formats. so I think it isn't even a bug in gnome-control-center nor gnome-settings-daemon at all. could be a RFE perhaps though.
(In reply to Akira TAGOH from comment #5) > From the quote from glibc docs > (https://www.gnu.org/savannah-checkouts/gnu/libc/manual/html_node/Locale- > Categories.html): > > LC_CTYPE > This category applies to classification and conversion of characters, and to > multibyte and wide characters; see Character Handling, and Character Set > Handling. > > So it isn't about the formats. so I think it isn't even a bug in > gnome-control-center nor gnome-settings-daemon at all. could be a RFE > perhaps though. Done, there was an open bug, I requested them to handle LC_CTYPE: https://bugzilla.gnome.org/show_bug.cgi?id=690750
(In reply to Mauricio Silveira from comment #3) > Yes, I use GNOME ( I've always been kind of KDE/Plasma, but it got really > buggy and I got used to and switched to GNOME in Fedora22 ). Interested in the problems in Plasma. > First, I had no idea of the "$HOME/.config/ibus/Compose" file usage. After > copying ( I could have made a link ), QT worked! The format is same in /usr/share/X11/$locale/.../Compose and see man Compose(5). > Then, I got back to my "/etc/X11/xinit/xinitrc.d/99-force-im.sh" and changed > it to: > #!/bin/bash > export GTK_IM_MODULE=ibus I think the file is no longer needed for your purpose. GNOME use ibus or gtk-im-context-simple but I implemeted the compose table in both. For GTK3, $HOME/.Compose or $HOME/.config/gtk-3.0/Compose > All working fine now except for gnome-terminal. If I copy/past ç into > gnome-terminal, it displays correctly, but trying to get ç via '+c still > results in ć. I think gnome-terminal won't inherit 99-force-im.sh because the entity is gnome-terminal-server and it's invoked by dbus-daemon which does not inherit 99-force-im.sh . But anyway, you can use the compose tables with GTK3 too. > About LC_CTYPE: > > My system is set to en_US and formats to Brasil ( GNOME settings ) > The output from "env | grep LC" is : > LC_PAPER=pt_BR.UTF-8 > LC_MONETARY=pt_BR.UTF-8 > LC_NUMERIC=pt_BR.UTF-8 > LC_MEASUREMENT=pt_BR.UTF-8 > LC_TIME=pt_BR.UTF-8 > > And the output of "locale" command is: > LANG=en_US.UTF-8 > LC_CTYPE="en_US.UTF-8" > LC_NUMERIC=pt_BR.UTF-8 > LC_TIME=pt_BR.UTF-8 > LC_COLLATE="en_US.UTF-8" > LC_MONETARY=pt_BR.UTF-8 > LC_MESSAGES="en_US.UTF-8" > LC_PAPER=pt_BR.UTF-8 > LC_NAME="en_US.UTF-8" > LC_ADDRESS="en_US.UTF-8" > LC_TELEPHONE="en_US.UTF-8" > LC_MEASUREMENT=pt_BR.UTF-8 > LC_IDENTIFICATION="en_US.UTF-8" > LC_ALL= > > Should LC_CTYPE have been set to pt_BR.UTF-8 ? If you set pt_BR.UTF-8, you can get ccedilla without having $HOME/**/*Compose. You can choose one of either customizing Compose file or setting LC_CTYPE. (In reply to Mauricio Silveira from comment #4) > Updating: > > 1.) Cleared im-chooser settings, removed > "/etc/X11/xinit/xinitrc.d/99-force-im.sh" - result: GTK_IM_MODULE is not set Right. GNOME uses a gsettings value instead. There is a bit complicated settings. If you sets XKB input sources only on `gnome-control-center region`, all input sources will use gtk-im-context-simple. If you add one more IM input sources on `gnome-control-center region`, all input sources will use ibus. E.g. one of IM is "English (United States)" -> "English (English US (Hunspell))" So I guess your desktop uses gtk-im-context-simple but not ibus. But you can use $HOME/.Compose or $HOME/.config/gtk-3.0/Compose . > Restored "/etc/X11/xinit/xinitrc.d/99-force-im.sh" > > 2.) Removed "$HOME/.config/ibus/Compose", system reboot - result: It got > back to typing ć as expected ( ibus had the ç Compose cached ) > > 3.) edited /etc/locale.conf and added LC_CTYPE=pt_BR.UTF-8, logged out and > in - result: nothing changed > system rebooted : Wotking as expected, now '+c is ç , even gnome-terminal > worked! > > 4.) Now that setting LC_CTYPE fixed everything, I removed > "/etc/X11/xinit/xinitrc.d/99-force-im.sh", rebooted - result: as expected, > GTK_IM_MODULE is not set BUT everything is working fine with ç Ç Looks good.
A bit more of discussion here: https://bugzilla.gnome.org/show_bug.cgi?id=690750 After some research about LC_CTYPE, I don't think it is the right way to handle input setting anymore... In fact it is more complicated than that. I think us_intl should have been kept as it's always been since the DOS ages, and a new layout us_slav should handle the characters with acute such as śŕṕń . I've just found out that my layout is writing śṕńḿ... In fact I'll go further ahead and make the pt_BR.UTF-8 to include AltGr+, to write ć ( make it work the opposite way ) The pt_BR.UTF-8 Compose includes en_US.UTF-8 and adds some modifications... I'll have to drop this discussion for a while, as I have much to do... I'll double check if previous versions ( I have Fedora22 in my laptop ) have the same behavior... On a second thought... if LC_CTYPE is not the way to handle input selection... why every component that handles input ( ibus, gtk, gnome-terminal, etc ) respects this setting? More on this later...
(In reply to Mauricio Silveira from comment #8) > A bit more of discussion here: > https://bugzilla.gnome.org/show_bug.cgi?id=690750 > After some research about LC_CTYPE, I don't think it is the right way to > handle input setting anymore... That has been the right way in the legacy settings. You can see /usr/share/X11/locale/*/Compose depends on the locales. Normally someone has been set LC_MESSAGES=en_US.UTF-8 and LC_CTYPE=foo and configured the input and font settings. I think the problem is we lack LC_foo for input and font settings. I agree to think the more serviceable definitions. I think one of the possible solution is to provide new variables likes IBUS_LANG and GTK_LANG. But this case could resolve with $HOME/.config/ibus/Compose or $HOME/.config/gtk-3.0/Compose
Mauricio: Did you confirm GNOME and compose keys work fine as I explained?
I think this should be closed since both IBus and GtkIMContextSimple provides the configuration file as I explained in comment #9.
closing.