Bug 1374888

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.