Bug 597305

+++ This bug was initially created as a clone of Bug #505100 +++

I'm noticing this bug after upgrading my desktop to RHEL6.

Description of problem:

We have a problem with the keyboard Us Internacional.
I'm using Fedora 11 in pt_BR

Looking the file /lib/kbd/keymaps/i386/qwerty/us-acentos.map.gz, I found this:

compose '\'' 'C' to 'Ç'
compose '\'' 'c' to 'ç'

This is correct, but, when I press  ' + c or ' + C =  ć or Ć.

In portuguese we don't have acent in the c, the correct is ç  (C + cedilla) 

Version-Release number of selected component (if applicable):
rpm -qf /lib/kbd/keymaps/i386/qwerty/us-acentos.map.gz

The package is kbd-1.15-7.fc11.i586 

How reproducible:

Choose the pt_BR locale and the US ACENTOS(US International) keyboard layout

  
Actual results:
when I press  ' + c or ' + C =  ć or Ć.

Expected results:
ç  (C + cedilla) 

Additional info:

> Use [RAlt]+[,] and [c] to get ç.
>
>          Kevin Kofler
>

It works, but we can't change the default way to use the us_acentos(US International) keyboard.

Since Fedora 1 and in all others OS like windows and others distros when we choose the pt_BR language and the US Internacional keyboard when we press C + ' we have = ç

--- Additional comment from kevin@tigcc.ticalc.org on 2009-06-10 20:08:53 EDT ---

As I wrote in my mail, this is a feature. The US International layout supports many languages, including languages which do have a ć. The whole point is to be INTERNATIONAL. Making the layout behave differently based on the system locale makes no sense at all.

--- Additional comment from ehabkost@redhat.com on 2009-06-10 20:43:42 EDT ---

The point of localization is to make the system more accessible to people from different countries. The way people type "ç" in Brazil is typing the ['] key and then [c]. Asking the user to use a different method is like asking the user to switch to a different keyboard layout. I would say that in practice, we use a different keyboard layout, even if the labels on the physical keyboard look the same.

I don't know how this can be implemented in the end (maybe it is already implemented using some layout variation and I don't know it), but this is an essential feature for making Fedora acessible for the brazilian audience. If this is not considered a bug, then consider this a feature request, then.

--- Additional comment from kevin@tigcc.ticalc.org on 2009-06-10 20:59:36 EDT ---

There needs to be a us-brazil or something layout then. Redefining us-intl based on locale is a bad idea.

--- Additional comment from vcrhonek@redhat.com on 2009-06-11 08:06:16 EDT ---

E. g. the letter 'č' is used in Czech Republic (and no other accent with 'c'). It's not possible to have everything included in one keymap.

There are four Brazilian keymaps in /lib/kbd/keymaps/i386/qwerty, please use one of them.

--- Additional comment from kevin@tigcc.ticalc.org on 2009-06-11 14:49:56 EDT ---

From http://en.wikipedia.org/wiki/Ć:
"It is the fifth letter of: Polish, Sorbian, Croatian, and Bosnian alphabets, as well as the Latin forms of Serbian, and Macedonian (in some forms)[1]. It is fourth in the Belarusian Łacinka alphabet."

--- Additional comment from rodrigopadula@projetofedora.org on 2009-06-11 15:57:41 EDT ---

The question is:

Since Fedora 1 to Fedora 9, when we press c + ' we had = ç

This is the default way in pt_BR locale with US International keyboard to do it in Windows, Solaris, Mac/OS and all Linux distributions, including Fedora 1 to 9!

We are receiving a lot of claims in Brasil since Fedora 9 about this! We can't force the users to change the default way to use the keyboard.

This is a big usability problem for Brazilians. Fedora is used by many governments departments, companies  and schools. We can't force this users to change the way to write or to buy new keyboards.

--- Additional comment from ehabkost@redhat.com on 2009-06-15 10:42:10 EDT ---

(In reply to comment #4)
> 
> There are four Brazilian keymaps in /lib/kbd/keymaps/i386/qwerty, please use
> one of them.  

I didn't test it, but it looks like the br-latin1-us keymap is what I was looking for (a US layout keymap with deadkeys for brazilian audience).

I don't know about the issues Rodrigo is seeing, however. Maybe there is a problem somewhere else, or Rodrigo expects Anaconda to display those layouts as options at install time. It isn't very clear to me what configuration options he tried, and what exactly is not working for him.

--- Additional comment from vcrhonek@redhat.com on 2009-06-15 11:36:50 EDT ---

Rodrigo, do you talk about text console, right? Because kbd contains only text console stuff, not stuff used with X server...

"loadkeys /lib/kbd/keymaps/i386/qwerty/us-acentos.map.gz" and typing "' + c" produced "ç" for me in _text console_.

Typing the same with "USA International (with dead keys)" produced "ć" in _gnome-terminal_.

System locale doesn't matter.

--- Additional comment from petersen@redhat.com on 2009-06-17 03:19:13 EDT ---

If this is a issue in gtk apps then I suggest trying to install the gtk-immodules package, which includes the cedilla immodule - no longer installed by default in F11 gtk2.

--- Additional comment from brunojcm@gmail.com on 2009-06-17 19:59:50 EDT ---

I'm using Fedora 11 and having the same problem with ç. I think it's not correct to say that's not a bug, because people in Brazil always use ' +  c to put the ç.

It's true that running 'loadkeys /lib/kbd/keymaps/i386/qwerty/us-acentos.map.gz' or 'loadkeys /lib/kbd/keymaps/i386/qwerty/br-latin1-us.map.gz' makes ' + c put a ç in _text console_, as says Vitezlav, but ã is not working on these keymaps.

I think it's a really big mistake not installing gtk2-immodules by default, because we can hold on without ç in text console, but in gnome it's infeasible. 
I needed to install this package, edit /etc/X11/xinit/xinput.d/none.conf to use the cedilla im and include "en" on the cedilla line of 
/etc/gtk-2.0/x86_64-redhat-linux-gnu/gtk.immodules to get ç working properly on gnome.
What package can I fill a bug against?

--- Additional comment from vcrhonek@redhat.com on 2009-06-18 02:20:41 EDT ---

(In reply to comment #10)
> I'm using Fedora 11 and having the same problem with ç. I think it's not
> correct to say that's not a bug, because people in Brazil always use ' +  c to
> put the ç.
> 
> It's true that running 'loadkeys
> /lib/kbd/keymaps/i386/qwerty/us-acentos.map.gz' or 'loadkeys
> /lib/kbd/keymaps/i386/qwerty/br-latin1-us.map.gz' makes ' + c put a ç in _text
> console_, as says Vitezlav, but ã is not working on these keymaps.

If 'ã' should work in Brazilian keymaps (i. e. not in us-acentos;)), please fill a new bug and we should fix it with kbd upstream.

> 
> I think it's a really big mistake not installing gtk2-immodules by default,
> because we can hold on without ç in text console, but in gnome it's infeasible. 
> I needed to install this package, edit /etc/X11/xinit/xinput.d/none.conf to use
> the cedilla im and include "en" on the cedilla line of 
> /etc/gtk-2.0/x86_64-redhat-linux-gnu/gtk.immodules to get ç working properly on
> gnome.
> What package can I fill a bug against?  

I'll change component to xkeyboard-config - keymaps in X generally, that's probably it. If not, feel free to reassign it accordingly.

--- Additional comment from petersen@redhat.com on 2009-06-18 19:50:20 EDT ---

Do you have a Brazilian or US keyboard?

If you login to your desktop after choosing one of the Brazilian keyboards
in the GDM keyboard menu, it does not work for you?

--- Additional comment from rodrigopadula@projetofedora.org on 2009-06-18 22:30:28 EDT ---

I'm using US keyboard + pt_br language in my system!

Since fedora 1 and in all OS with pt_BR support, when whe choose the pt_BR language and US International Keyboard(US Acentos) when we press ' + c we have = ç but it isn't happen using fedora 10 and 11.

The keyboard and language was defined during the Fedora 10 and 11 installations and re-seted after the installation, the problem persist in text and GUI modes.

--- Additional comment from dchen@redhat.com on 2009-06-19 02:48:50 EDT ---

Rodrigo,

What you actually need is a Brazilian input method,
which, as Jens points out, in gtk2-immodules.
You may also need to install gtk2-immodules-xim, if there is no Qt equivalent.

Previous Fedora works because they install gtk2-immodules for you.

Keyboard guru Peter mentioned a simple rule:
If the character does not print on your keyboard, or not the place you want, 
use an input method.

--- Additional comment from brunojcm@gmail.com on 2009-06-23 13:17:36 EDT ---

Can I report a bug against gtk2-immodules asking for installing it by default?

It is really surprising that the same method of putting ç, which works in all other versions of fedora and other OS'es not working out of the box in Fedora 11. I think it's really inhibiting people to use Fedora 11 in Brazil.

--- Additional comment from rodrigopadula@projetofedora.org on 2009-07-05 22:42:26 EDT ---

So, we need to install gtk2-immodules and  gtk2-immodules-xim by default.

We are receiving a lot of claims about this problem in the Brazilian lists and Forum.

How we can add this packages by default as a dependency of a keyboard/localization package ?

It's very important to be corrected ASAP.

--- Additional comment from petersen@redhat.com on 2009-07-08 00:58:52 EDT ---

(In reply to comment #16)
> So, we need to install gtk2-immodules and  gtk2-immodules-xim by default.

gtk2-immodules-xim is not needed.

> We are receiving a lot of claims about this problem in the Brazilian lists and
> Forum.

But can't you see im-cedilla.so (from gtk2-immodules) is gtk specific so it won't work consistently across the distro, eg in KDE, etc.

Sorry, it does not seem to be the Right solution I am afraid
but looks more like a hack.

You didn't answer the question about trying to use a Brazilian
layout instead of US International.  Could you please try
that at least from gdm login and report your experience?

--- Additional comment from ehabkost@redhat.com on 2009-07-08 09:59:48 EDT ---

(In reply to comment #17)
> 
> You didn't answer the question about trying to use a Brazilian
> layout instead of US International.  Could you please try
> that at least from gdm login and report your experience?  

I don't think there is a keyboard layout on the list that is equivalent to us-international + cedilla (that is what brazilian user expect when they have a US keyboard), but I still need to check the keyboard layout list, just in case.

On my Fedora 10 machine I configured KDE to use '-layout us -variant alt-intl', and cedilla is working as expected. I don't know if there is an option for this on Anaconda or GDM, though.

--- Additional comment from rodrigopadula@projetofedora.org on 2009-07-09 12:29:40 EDT ---

After the gtk2-immodules installation is necessary to change the file /etc/X11/xinit/xinput.d/none.conf

Line: GTK_IM_MODULE=gtk-im-context-simple 
To: GTK_IM_MODULE=gtk-im-cedilla

--- Additional comment from brunojcm@gmail.com on 2009-07-09 12:50:25 EDT ---

Here I'm using a US keyboard and need cedilla.

I tried all formats of "System > Preferences > Keyboard > Layout" without success.
None of the "Brazil" variants matches the US international layout and if I choose "United States" there is not a variant that gives me the cedilla behaviour.

The only way I could make it work was selecting "United States", variant "USA Alternative international (former us_intl)", and installing de gtk2-immodules and editing /etc/gtk-2.0/x86_64-redhat-linux-gnu/gtk.immodules to put ":en" on the end of cedilla line.

I agree with Eduardo, there is not a keyboard layout on the list that is equivalent to "US International + cedilla".

I have a Windows VM on this Fedora and just select Language "Português (Brazil)", layout "United States (International)" and everything is working properly.

PS. I have another issue here: When I press " two times, i get ¨ instead of "". When a press ' two times, i got a ´ instead of ''. It's not the desired behaviour, but I'm not sure it's layout fault.

Thanks for all!

--- Additional comment from kevin@tigcc.ticalc.org on 2009-07-09 13:01:45 EDT ---

Re your PS, that's also a feature.

--- Additional comment from ehabkost@redhat.com on 2009-07-09 13:23:46 EDT ---

(In reply to comment #20)
> 
> PS. I have another issue here: When I press " two times, i get ¨ instead of "".
> When a press ' two times, i got a ´ instead of ''. It's not the desired
> behaviour, but I'm not sure it's layout fault.

I think this is the expected behaviour.

Press ['] two times, to get: ´
Press ['] then spacebar, to get: '
Press ["] two times, to get: ¨
Press ["] then spacebar, to get: "

I think it always worked that way, didn't it?

--- Additional comment from brunojcm@gmail.com on 2009-07-09 14:44:53 EDT ---

(In reply to comment #22)
> I think this is the expected behaviour.
> 
> Press ['] two times, to get: ´
> Press ['] then spacebar, to get: '
> Press ["] two times, to get: ¨
> Press ["] then spacebar, to get: "
> 
> I think it always worked that way, didn't it?  

I'm not sure about this because it's the first time I use Fedora with US keyboard.. all my others boxes have a brazilian ABNT2 keyboard, with works very well with the Brazilian layout.

It would be more useful if the behaviour was like I described above in a new "Brazilian US International Keyboard" likely layout, because here in Brazil we don't use [¨] and [´] frequently, and it would seems more with Windows behaviour, users could feel less strange on migrations, etc. 

But I think it's a little off-topic, the real problem in Brazil is actually the cedilla, not it.

Thanks for all!

--- Additional comment from dchen@redhat.com on 2009-07-09 20:30:39 EDT ---

Rodrigo,

Modifying default behaviour of none.conf may upset other people that use it.

It looks like Vitezslav is going to help you by providing a Brazilian keyboard layout/map
for kbd and X. How about, as he said, open another bug so he can work on that?

Alternatively, you can make an Brazilian input method for IBus. :-)

--- Additional comment from tagoh@redhat.com on 2009-07-09 21:01:30 EDT ---

Created an attachment (id=351200)
im-cedilla.conf

Just a suggestion if using cedilla immodule in gtk+ is a solution:

How about put im-cedilla.so to the separate package like gtk-immodules-cedilla with the attached imsettings configuration file? you could update comps to require that package for Brazilian Portuguese Language Support then. although you need to choose that with im-chooser manually and need a bit updates on imsettings to support immodule only configuration.

As Ding suggested, supporting cedilla in IBus may be the right way to go. we can enable IM for pt_BR and no need to do something with im-chooser basically then.

Anyway, just for an idea.

--- Additional comment from petersen@redhat.com on 2009-07-09 21:02:30 EDT ---

This bug should be fixable at the xkb level IMHO without using immodule hacks.

Moving to xkeyboard-config based on comment 18.

(Please a separate bug for any quoting issues.)

--- Additional comment from petersen@redhat.com on 2009-07-09 21:04:15 EDT ---

(In reply to comment #25)
> How about put im-cedilla.so to the separate package like gtk-immodules-cedilla
> with the attached imsettings configuration file? you could update comps to
> require that package for Brazilian Portuguese Language Support then. although
> you need to choose that with im-chooser manually and need a bit updates on
> imsettings to support immodule only configuration.

Good point - we can certainly do that too - in fact doesn't require
subpackaging per se.

But I think the first attempt should be to fix this correctly with xkb support.

--- Additional comment from petersen@redhat.com on 2009-07-10 02:37:01 EDT ---

(In reply to comment #25)
> Created an attachment (id=351200) [details]
> im-cedilla.conf

I opened bug 510666 to rfe adding xinput .conf to gtk2-immodules.

--- Additional comment from rafael.espindola@gmail.com on 2009-07-13 17:32:04 EDT ---

Just tried every combination of keyboards in

By language -> Portuguese
By country -> Brazil
By country -> United States

None has the desired effect of ' + c producing a ç.

No having such a layout (I don't care about the name) is a major usability problem.

Also, the layout should work in any application, using a gtk specific fix is not the way to go...

--- Additional comment from petersen@redhat.com on 2009-09-01 20:23:20 EDT ---

Hmm, what do other (commercial) OS's do for this?

--- Additional comment from ehabkost@redhat.com on 2009-09-02 10:45:52 EDT ---

On every pt_BR version of Windows I remember, the "US International" keyboard layout was the US keyboard layout where '+c produced ç.

That's why the current behaviour is confusing for brazilian users coming from Windows. It is confusing even for former Linux users because on older Linux distributions, the US International keyboard layout on Xorg used to produce ç instead of ć.

I have just checked this on a pt_BR Windows XP machine, and I get the expected behaviour if I select: language=EN, layout="US international" on the keyboard-layout applet.

I don't know what would be the best solution for this, however.

--- Additional comment from brunojcm@gmail.com on 2009-09-02 22:42:56 EDT ---

Rafael and Eduardo just confirmed what people said all the time along this thread. All OS'es in all versions i know produced ç with ' + c until Fedora 11. 

I don't know how people who uses the ć configured their keyboard up to now, but they should have a way. Brazilian people with US keyboard layout don't have a way anymore. Fedora 11 changes the default behaviour without provide an alternative. As said Rafael, it's a major usability problem.

Even the workaround proposed by me on Comment #20 works anymore, problably because some update I can't identify.

I just don't understand why this behaviour changed occurred.. but I hope it's really necessary and the change worth enough. 

If someone have another workaround, i would really appreciate to know.

Thanks

--- Additional comment from petersen@redhat.com on 2009-09-03 06:33:06 EDT ---

(In reply to comment #32)
> Rafael and Eduardo just confirmed what people said all the time along this
> thread. All OS'es in all versions i know produced ç with ' + c until Fedora 11. 

So I think we need a xkb layout with dead_acute + c -> ç.

> I don't know how people who uses the ć configured their keyboard up to now, but
> they should have a way. Brazilian people with US keyboard layout don't have a
> way anymore. Fedora 11 changes the default behaviour without provide an
> alternative. As said Rafael, it's a major usability problem.

Dumb question probably: using the Brazil layout which has a Ç key
would not be good enough?

> I just don't understand why this behaviour changed occurred.. but I hope it's
> really necessary and the change worth enough. 

Well it changed because we thought that the old gtk2 immodules
are mostly hacks and should not be installed by default in Fedora.

--- Additional comment from ehabkost@redhat.com on 2009-09-03 08:19:45 EDT ---

(In reply to comment #33)
> 
> Dumb question probably: using the Brazil layout which has a Ç key
> would not be good enough?

Not if your machine's keyboard has US layout and doesn't have a ç key.  :)

BR ABNT2 keyboards are also common in Brazil, but they have a completely different physical key layout (among other differences, you have an actual ç key on the keyboard). The problem here is for users who have US keyboards.

--- Additional comment from petersen@redhat.com on 2009-09-17 03:11:09 EDT ---

I see "us(intl)" has Alt_R + comma mapping to ccedilla.
Does that help at all?

What layout do people want to base on?

--- Additional comment from rafael.espindola@gmail.com on 2009-09-17 09:06:41 EDT ---

(In reply to comment #35)
> I see "us(intl)" has Alt_R + comma mapping to ccedilla.
> Does that help at all?

Helps, but having the same behavior as previous versions (and windows) is better.

> What layout do people want to base on?  

I think a us-intl with the '+c patched to produce ç would be perfect.

--- Additional comment from rodrigopadula@projetofedora.org on 2009-09-17 10:39:52 EDT ---

Problem fixed.

https://bugzilla.redhat.com/show_bug.cgi?id=510666

--- Additional comment from kevin@tigcc.ticalc.org on 2009-09-17 18:16:16 EDT ---

I think that's not a real fix, just a hack. It'll lead to GTK+ applications doing something different than other apps (e.g. Qt apps).

--- Additional comment from petersen@redhat.com on 2009-09-17 20:38:22 EDT ---

(In reply to comment #36)
> I think a us-intl with the '+c patched to produce ç would be perfect.  

I think the only way to do that is to have "'" mapped to
dead_cedilla which is not what you want I suppose.

Peter, any comment?

Seems to me that using dead_acute for this was a Bad Idea
and people should rather get used to Alt_R Comma.

How about Alt_R c -> ç that seems common?

--- Additional comment from rafael.espindola@gmail.com on 2009-09-17 21:32:04 EDT ---

I keep my opinion that fixing this is GTK is wrong. It has to work on Qt and on plain X.

Alt_R c -> ç is a bit better (OS X is similar), but with windows being such a big part of the market I think the best it to just follow windows and keep the old behavior: ' + c -> ç.

--- Additional comment from petersen@redhat.com on 2009-09-17 21:58:42 EDT ---

Yes but how?

The only other idea I can offer is an m17n-contrib input-method:

Currently in fedora m17n-db-latin we have latn-post and latn-pre
which provide c, -> ç and ,c -> ç respectively (plus lots of
other accent bindings for qwerty), but it is trivial to make
map for 'c -> ç, etc.

--- Additional comment from rafael.espindola@gmail.com on 2009-09-17 22:09:39 EDT ---

There must be a way, that was the behavior in older versions of fedora :-)

Copying an old version of us-intl and renaming it to us-pt or us-pt_br should work, no?

--- Additional comment from petersen@redhat.com on 2009-09-17 22:47:06 EDT ---

(In reply to comment #42)
> Copying an old version of us-intl and renaming it to us-pt or us-pt_br should
> work, no?  

If you can attach it we can review.  Which version of Fedora?
Was X using the kernel us-acentos map then?


As I see it the current choices are:

A) use dead_cedilla (only needed for ccedilla)
B) define ccedilla on a key (us(intl) provides it on Alt_R comma)
C) use an input method to implement it.

I think B or C are preferable.

--- Additional comment from rafael.espindola@gmail.com on 2009-09-17 23:17:21 EDT ---

comment #6 says Fedora 1 to 9.

C is not a fix IMHO
B using Alt_R + c is an improvement, but we would still have a regression
A I think this would fix the problem. In fact, I think that is how us-intl used to work

I just moved and don't have a Fedora machine with me right now. Should be able to test in one month.

--- Additional comment from rodrigopadula@projetofedora.org on 2009-09-18 00:17:16 EDT ---

In Kde and in text mode the ' + c = ç is working fine, without extra configurations.

I had problems only using gnome/gtk.

--- Additional comment from kevin@tigcc.ticalc.org on 2009-09-18 02:49:11 EDT ---

"Solution" A would not really fix your problem, you could no longer enter things like á, é, í, ó, ú (and ý if you need that one) nor the apostrophe itself if ' was mapped to dead_cedilla.

If I set the layout to us_intl in KDE (F10, KDE 4.3.1, de_AT.UTF-8 locale), I get ' + c = ć, not ç (and to be honest that's what I'd expect, especially from an *international* layout: if dead_acute + c is ç, how are people who want to type ć (needed at least for Polish and Croatian, and Serbian if written in Latin letters) supposed to get it?).

But I think this may well be locale-dependant: the Compose tables are in /usr/share/X11/locale/ and there's a special one for pt_BR.UTF-8 which maps dead_acute + c to ç (yuck!). So maybe what's going on is that GTK+ no longer uses the locale-specific table?

--- Additional comment from petersen@redhat.com on 2009-09-18 03:33:48 EDT ---

I dunno I just tried in rawhide kde and get ' + c = ć.

(In reply to comment #45)
> In Kde and in text mode the ' + c = ç is working fine, without extra
> configurations.

Console is using us-acentos presumably?
Please explain how to reproduce in KDE.

--- Additional comment from rafael.espindola@gmail.com on 2009-09-18 09:44:28 EDT ---

(In reply to comment #46)
> "Solution" A would not really fix your problem, you could no longer enter
> things like á, é, í, ó, ú (and ý if you need that one) nor the apostrophe
> itself if ' was mapped to dead_cedilla.

how about dead_acute + c = ç?
I remember that '+' used to be '

> If I set the layout to us_intl in KDE (F10, KDE 4.3.1, de_AT.UTF-8 locale), I
> get ' + c = ć, not ç (and to be honest that's what I'd expect, especially from
> an *international* layout: if dead_acute + c is ç, how are people who want to
> type ć (needed at least for Polish and Croatian, and Serbian if written in
> Latin letters) supposed to get it?).

Sure. Lets keep the us_intl what it is. It was enough pain to change it once. Just add a us_pt or something.

> But I think this may well be locale-dependant: the Compose tables are in
> /usr/share/X11/locale/ and there's a special one for pt_BR.UTF-8 which maps
> dead_acute + c to ç (yuck!). So maybe what's going on is that GTK+ no longer
> uses the locale-specific table?  

I think '+c was producing ć everywhere (xterm, mozilla, konsole, etc), but I might be wrong. Can anyone with a current Federa install check that?

--- Additional comment from petersen@redhat.com on 2009-09-23 05:08:00 EDT ---

(I think with Compose (Multi_key) you could have 
"Compose comma c" -> ç)

(In reply to comment #46)
> But I think this may well be locale-dependant: the Compose tables are in
> /usr/share/X11/locale/ and there's a special one for pt_BR.UTF-8 which maps
> dead_acute + c to ç (yuck!). So maybe what's going on is that GTK+ no longer
> uses the locale-specific table?  

Oh yes - new to me...

> So maybe what's going on is that GTK+ no longer
> uses the locale-specific table?  

You're right - the locale compose seems to work
for X11 and KDE apps.

So seems indeed GTK is inconsistent here.

--- Additional comment from petersen@redhat.com on 2009-09-23 05:17:45 EDT ---

An extra wrinkle is that IM (at least ibus) seems to break
the locale compose in KDE, but I assume you don't need
input methods for now.

--- Additional comment from mclasen@redhat.com on 2009-09-24 10:40:20 EDT ---

GTK itself has never used the X compose tables, we have our own builtin table.
And that table does in fact contain sequences for ç. E.g. try 
Compose_key , c
Compose_key c ,

If you want to use the X compose tables in GTK+, you have to use xim.

--- Additional comment from ehabkost@redhat.com on 2009-09-24 11:51:21 EDT ---

(In reply to comment #51)
> GTK itself has never used the X compose tables, we have our own builtin table.
> And that table does in fact contain sequences for ç. E.g. try 
> Compose_key , c
> Compose_key c ,
> 
> If you want to use the X compose tables in GTK+, you have to use xim.  

Sorry for the ignorance, but what does that mean for users that don't know what Input Methods are, have a US keyboard, install Fedora in pt_BR, and expect [']+[c] to produce [ç]?

--- Additional comment from petersen@redhat.com on 2009-09-28 04:23:01 EDT ---

I haven't succeeded yet in getting X compose working with im-xim.so
- so would appreciate receiving clues/steps to do that. :)
Is "GTK_IM_MODULE=xim" sufficient?

(In reply to comment #52)
> > If you want to use the X compose tables in GTK+, you have to use xim.  
> 
> Sorry for the ignorance, but what does that mean for users that don't know what
> Input Methods are, have a US keyboard, install Fedora in pt_BR, and expect
> [']+[c] to produce [ç]?  

IIUC it means that if one enables XIM on the desktop then
your [']+[c] should work for pt_BR in gtk apps.

However as I say above I haven't succeeded yet with doing that.

--- Additional comment from petersen@redhat.com on 2009-09-28 05:15:14 EDT ---

Nm, Tagoh-san pointed me in the right direction.

- Need to make sure gtk2-immodule-xim is installed. ;)
- Login from gdm with lang=pt_BR.UTF-8 and kbd=us(intl).
- Run $ GTK_IM_MODULE=xim gedit.
- Enter [']+[c] to produce [ç].
- Game over. :)

But we need some imsettings to allow turning on
XIM in this case.

--- Additional comment from ehabkost@redhat.com on 2009-09-28 07:16:44 EDT ---

Once this is fixed, will it be enabled by default on pt_BR + US-intl-keyboard installs?

--- Additional comment from mclasen@redhat.com on 2009-09-28 10:08:35 EDT ---

Jens, imsettings installs a file called /etc/X11/xinit/xinput.d/xim.conf. Is that not enough to make xim available via imsettings ?

--- Additional comment from tagoh@redhat.com on 2009-09-28 21:46:32 EDT ---

(In reply to comment #56)
> Jens, imsettings installs a file called /etc/X11/xinit/xinput.d/xim.conf. Is
> that not enough to make xim available via imsettings ?  

Since the most XIM servers requires the certain locale to work, it just provides the proper XIM servers for current locale to the users if available. xim.conf itself isn't useful if no xinput files are installed.

You may need something like /etc/X11/xinit/xinput.d/xcompose with:
XIM=none
XIM_PROGRAM=/bin/true
XIM_ARGS=
SHORT_DESC="X locale compose"
GTK_IM_MODULE=xim
QT_IM_MODULE=xim

and in %post
%{_sbindir}/update-alternatives --install %{_sysconfdir}/X11/xinit/xinput.d/pt_BR xinput-pt_BR %{_sysconfdir}/X11/xinit/xinput.d/xcompose 50

%postun
%{_sbindir}/update-alternatives --remove xinput-pt_BR %{_sysconfdir}/X11/xinit/xinput.d/xcompose


I'm not sure if there are any requirements that people wants to use X compose regardless of current locale anyway. if there are, it may be good to not depend on xim.conf but put it as a standalone xinput file like scim and ibus does.

FWIW there are a bug in imsettings if the system locale is different to what one gives to imsettings-* command and im-chooser say. so if you are going to test it with LANG=pt_BR.UTF-8 im-chooser or so, you may see an error message then. FYI

I'll file a bug for that.

--- Additional comment from petersen@redhat.com on 2009-09-28 23:22:54 EDT ---

(In reply to comment #57)
> and in %post
> %{_sbindir}/update-alternatives --install
> %{_sysconfdir}/X11/xinit/xinput.d/pt_BR xinput-pt_BR
> %{_sysconfdir}/X11/xinit/xinput.d/xcompose 50
> 
> %postun
> %{_sbindir}/update-alternatives --remove xinput-pt_BR
> %{_sysconfdir}/X11/xinit/xinput.d/xcompose
> 
> I'm not sure if there are any requirements that people wants to use X compose
> regardless of current locale anyway. if there are, it may be good to not depend
> on xim.conf but put it as a standalone xinput file like scim and ibus does.

I think we should support X compose for any locale in principle
so I suggest not to make it locale specific and call the xinput.d
file say "xcompose.conf".  (Is the name "X compose" broad enough
to cover it?)

Also I am not sure it needs to set QT_IM_MODULE though it probably
doesn't hurt, or does Qt work because XIM is the default immodule
anyway?

--- Additional comment from tagoh@redhat.com on 2009-09-29 01:37:32 EDT ---

(In reply to comment #58)
> Also I am not sure it needs to set QT_IM_MODULE though it probably
> doesn't hurt, or does Qt work because XIM is the default immodule
> anyway?  

That may depends on how people set up on qtconfig. so it would be better adding that line too unless we don't mind either.

--- Additional comment from tagoh@redhat.com on 2009-10-01 09:00:38 EDT ---

(In reply to comment #58)
> I think we should support X compose for any locale in principle
> so I suggest not to make it locale specific and call the xinput.d
> file say "xcompose.conf".  (Is the name "X compose" broad enough
> to cover it?)

Or we could update none.conf to use im-xim.so but with XMODIFIERS=@im=none instead of gtk-im-context-simple. it doesn't requires the extra configurations. and it will keeps consistency among all of applications on X.

--- Additional comment from petersen@redhat.com on 2009-10-01 23:27:10 EDT ---

Sounds good to me - good idea :)

--- Additional comment from tagoh@redhat.com on 2009-10-02 02:56:07 EDT ---

I was trying to remember why I didn't make such change before.

The impact on this change would be one has to restart their desktop after turning off/on IM every time since we stop imsettings-applet running by default and it depends on the change of XMODIFIERS anyway.

Another concern is, some applications might becomes unstable when switching IM - one might freezes, one might crash etc - particularly when XMODIFIERS isn't @im=none.

I've just brought up an idea. but not sure if it's really good.

--- Additional comment from rodrigopadula@projetofedora.org on 2009-10-28 15:08:17 EDT ---

I'm trying Fedora 12 Beta and the problem is the same with this new version.

When I choose Brazilian Portuguese and keyboard US International:

' + c = ć not ç

It's a BIG usability problem for Brazilians because great part of our laptops are imported and the default keyboard is US International.

--- Additional comment from rosset.filipe@gmail.com on 2009-10-29 09:32:57 EDT ---

On Fedora 12 Beta ' + c = ç works with this steps...

yum install gtk2-immodules
System->Preferences->Input Methods-> Enable im-cedilla
Logoff

GDM Login
 PT_BR
 us_international (with dead keys)

Tested on Firefox 3.5.4, Xchat 2.8.6, OpenOffice 3.3.1, Gedit 2.28.0, gnome-terminal 2.28.1

--- Additional comment from rodrigopadula@projetofedora.org on 2009-10-29 09:58:20 EDT ---

Yes, it works since fedora 11, but, the Ç on US International keyboards  must work automatically when I choose the BR Portuguese language + US International Keyboard.

This is a big usability problem, mainly for new users.

--- Additional comment from rafael.espindola@gmail.com on 2009-10-29 11:12:46 EDT ---

(In reply to comment #64)
> On Fedora 12 Beta ' + c = ç works with this steps...
> 
> yum install gtk2-immodules
> System->Preferences->Input Methods-> Enable im-cedilla
> Logoff
> 
> GDM Login
>  PT_BR
>  us_international (with dead keys)
> 
> Tested on Firefox 3.5.4, Xchat 2.8.6, OpenOffice 3.3.1, Gedit 2.28.0,
> gnome-terminal 2.28.1  

This will not work on xterm or kterm or emacs, right?

--- Additional comment from rosset.filipe@gmail.com on 2009-10-29 11:21:51 EDT ---

(In reply to comment #66)
> (In reply to comment #64)
> > On Fedora 12 Beta ' + c = ç works with this steps...
> > 
> > yum install gtk2-immodules
> > System->Preferences->Input Methods-> Enable im-cedilla
> > Logoff
> > 
> > GDM Login
> >  PT_BR
> >  us_international (with dead keys)
> > 
> > Tested on Firefox 3.5.4, Xchat 2.8.6, OpenOffice 3.3.1, Gedit 2.28.0,
> > gnome-terminal 2.28.1  
> 
> This will not work on xterm or kterm or emacs, right?  

Im test now on:
 xterm                       x86_64                      248-2.fc12                         rawhide                      347 k


and works fine.

--- Additional comment from awilliam@redhat.com on 2009-10-29 13:36:41 EDT ---

Bruno Medeiros requested on fedora-test-list that this be nominated as an F12 Blocker, we will discuss at tomorrow's meeting, 15:00 UTC in #fedora-bugzappers . Please come along to discuss this issue if you can.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

--- Additional comment from petersen@redhat.com on 2009-10-30 05:13:02 EDT ---

> and works fine.  

Because im-cedilla.conf configures XIM also,
so X compose takes care of the X apps.

But currently we can't see any easy way for imseetings
to make im-cedilla the default immodule for pt_BR.

--- Additional comment from tagoh@redhat.com on 2009-10-30 05:34:28 EDT ---

(In reply to comment #69)
> > and works fine.  
> 
> Because im-cedilla.conf configures XIM also,
> so X compose takes care of the X apps.
> 
> But currently we can't see any easy way for imseetings
> to make im-cedilla the default immodule for pt_BR.  

Even though it's XMODIFIERS=@im=none. in that sense, we could have the condition state in none.conf as well to enable im-cedilla for pt_BR and gtk-im-context-simple for others. what this way is better would be, it wouldn't need extra work to make it default for pt_BR users. it should works even after upgrading.

--- Additional comment from myllynen@redhat.com on 2009-10-30 09:03:22 EDT ---

I have read all the comments above and done quite some testing on Fedora 12 Beta. Below I summarize earlier findings, provide some additional information, and present one possible solution. Please feel free to complement my remarks if appropriate.

Dysfunctional ' + c for Brazilian Portuguese is just one symptom of a much wider issue we have here. What is actually happening when a new user logs in is that GTK's builtin compose rule table is used regardless of user's locale settings. Apparently with earlier Fedora releases one's locale settings (LC_CTYPE or LANG) caused X compose rules to be taken into use but currently there seems to be no way to do that with GTK applications.

Problems arise especially when these GTK builtin rules conflict with national/locale specific rules like in pt_BR or fi_FI. Using some character specific trick like im-cedilla is really not a feasible solution to the issue which literally covers thousands of compose rules.

With non-GTK applications like xterm one can easily see how locale settings affect the compose rules in use:

# yum install xterm xorg-X11-fonts-misc
$ LC_CTYPE=en_US.UTF-8 xterm &
$ LC_CTYPE=fi_FI.UTF-8 xterm &
$ LC_CTYPE=pt_BR.UTF-8 xterm &

Simple test cases for these three example locales are:

dead_acute + c produces ć if using X's en_US.UTF-8/Compose (or GTK builtins)
dead_acute + c produces ç if using X's pt_BR.UTF-8/Compose
dead_acute + space produces ' if using en_US.UTF-8/Compose (or GTK builtins)
dead_acute + space produces ´ if using fi_FI.UTF-8/Compose

As mentioned several times in the earlier comments the default for Brazilian Portuguese is not acceptable. Situation with Finnish is also very challenging since there is an official national standard which defines both keyboard layout and compose rules. As explained above now it seems impossible to comply with this standard with Fedora 12 although X already implements everything what would be needed (i.e., both keyboard layout and X compose rules).

One possible solution to solve all the issues discussed here could be:

1. Use any Input Method system like IBus or SCIM if configured by the user
2. If no Input Method system configured use X/locale settings (default)
3. If both previous methods fail or are unavailable use GTK builtin rules

This scheme would mean that en_US users would not notice any difference compared to the current situation, users of locales like pt_BR and fi_FI would notice their keyboards working by default, and others who need an advanced input system (like ja_JP users) could enable it at will as always. It would also provide a consistent user experience when switching between GTK applications (e.g., gnome-terminal) and non-GTK applications (e.g., xterm). Also, if an individual compose rule or keymapping is found to be problematic within a locale, then it would be only a locale specific issue, no system level changes would be needed at all. And should there be changes needed for an Input Method system only those users who have enabled that particular Input Method system would be affected.

I will take part of the IRC session later today where we can discuss this issue in more detail.

Thanks.

--- Additional comment from petersen@redhat.com on 2009-10-30 10:01:24 EDT ---

Thank Marko for the good detailed summary and the Finnish perspective also.
(I am glad this also resurfaced in the i18n Test Day this week.)

(In reply to comment #71)
> Problems arise especially when these GTK builtin rules conflict with
> national/locale specific rules like in pt_BR or fi_FI. Using some character
> specific trick like im-cedilla is really not a feasible solution to the issue
> which literally covers thousands of compose rules.

Right - as also noted here earlier.

> 1. Use any Input Method system like IBus or SCIM if configured by the user
> 2. If no Input Method system configured use X/locale settings (default)
> 3. If both previous methods fail or are unavailable use GTK builtin rules

My suggests are:

1) avoid im-cedilla.so
2) install gtk2-immodules-xim by default
(or better move im-xim.so back into gtk2?)
3) try to make im-xim.so the default gtk immodule
(which corresponds to Marco's (2) instead of
gtk-im-context-simple, as Akira also suggested.
4) everyone (gtk, qt, X) happy

In fact I have pushed for this in the past (see bug 452938)
to bring parity with qt which has long defaulted to XIM
(probably because of its European heritage?:)

I think fedora-i18n can help to work on this in the coming days,
though it is getting rather late for f12-final...
It might be more realistic to target day-zero updates to
not risk destabilizing and further delaying the release
at this stage: I think that was our original intention.

--- Additional comment from awilliam@redhat.com on 2009-10-30 14:17:21 EDT ---

Discussed at the blocker bug meeting today. The thing that worries me is that if we fix this as a 0-day update it won't be fixed during installation. However, I've been told that the need to type a ç during installation is likely to be quite small for most Brazilian users, so on that basis we agreed that dropping it to F12Target and aiming to fix it with a 0-day update is OK.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

--- Additional comment from mclasen@redhat.com on 2009-10-30 14:22:38 EDT ---

I don't want to bring xim back into the main gtk package. Imo, this is a step
back. We need to have a single input method framework that actually works for
everybody, not a patchwork where you have to pick whatever works best for your
language.

--- Additional comment from kevin@tigcc.ticalc.org on 2009-10-30 14:26:32 EDT ---

It's also not really true that Qt uses XIM by default. We don't even ship XIM on the KDE spin. It might pick it up by default if you install it (and no other input method package), but normally there's no XIM installed at all.

--- Additional comment from petersen@redhat.com on 2009-10-31 06:17:03 EDT ---

(In reply to comment #74)
> I don't want to bring xim back into the main gtk package.
> Imo, this is a step back. 

What is the problem with replacing gtk-im-context-simple with
im-xim.so as the default IM context?

I see it as a step forward not a step back. :)

> We need to have a single input method framework that actually works for
> everybody, not a patchwork where you have to pick whatever works best for your
> language.  

Well I would like that ibus can also handle X compose better:
hopefully for f13 but rather unlikely for f12 release...
we need a fix now this has been broken since f11. :-(

It is not a patchwork but consistent with qt's behaviour.

(In reply to comment #75)
> It's also not really true that Qt uses XIM by default.

Erm, we are talking about qt immodules here -
sorry for being unclear perhaps: try running
"QT_IM_MODULE=  qtconfig-qt4" -> Interface
and looking at "Default Input Method".

Anyway Qt already works the discussion here is about
X and gtk apps.

--- Additional comment from petersen@redhat.com on 2009-10-31 07:29:05 EDT ---

Created an attachment (id=366913)
imsettings-none.conf-xim.patch

My recommendation to fix this serious problem for International users:

Add to the comps-f12 input-methods group:

 <packagereq type="conditional" requires="gtk2">gtk2-immodule-xim</packagereq>

and apply the above patch to imsettings none.conf to make
imsettings default GTK_IMMODULE to xim when available.

My main remaining concern though is multilib issues: eg when users
have gtk2.x86_64 and gtk2.i686 installed but only gtk2-immodule-xim
for one arch.  For this reason I really wish Matthias will give
my idea to move im-xim.so back into the main gtk2 package
further consideration.

--- Additional comment from petersen@redhat.com on 2009-10-31 07:34:17 EDT ---

If people could test the above patch it would be appreciated
(be sure to turn-off IM in im-chooser to make sure you are
using none.conf, and restart your desktop session).
It seems to works well enough for me so far on i686 anyway.

--- Additional comment from mclasen@redhat.com on 2009-10-31 14:39:48 EDT ---

> Dysfunctional ' + c for Brazilian Portuguese is just one symptom of a much
> wider issue we have here. What is actually happening when a new user logs 
> in is that GTK's builtin compose rule table is used regardless of user's locale
> settings. Apparently with earlier Fedora releases one's locale settings
> (LC_CTYPE or LANG) caused X compose rules to be taken into use but currently
> there seems to be no way to do that with GTK applications.

Depends on what you mean with 'locale settings' here.

If you don't use an input method framework like scim or ibus (or iiimf or xim or whatever else is in vogue) you get whatever compose sequences that method provides, which may depend on your locale or not. 

If you don't use an input method framework, GTK+ uses its builtin simple input method, which has a large, but fixed table of compose sequences. 

This has always been the case. Nothing has changed in GTK+ here.

--- Additional comment from petersen@redhat.com on 2009-11-01 08:19:37 EST ---

(In reply to comment #79)
> This has always been the case. Nothing has changed in GTK+ here.  

Right.  What changed in F11 is we stopped installing
im-cedilla by default and hence this bug report.
(I was probably partly to blame for that decision:
not that it was wrong in itself, just that we didn't provide
a saner substitute, since I don't think we were aware then
of its wide use for pt_BR.)

It seems clear now that im-cedilla was merely a hack
to workaround the lack of X compose support in gtk-im-context-simple,
which is provided through im-xim.so.  Using im-xim.so
should give us consistent keyboard input for all locales
across X, GTK, and Qt applications which is a big usability plus
for users dependent on X compose for writing their language.

--- Additional comment from mclasen@redhat.com on 2009-11-01 09:25:21 EST ---

> It seems clear now that im-cedilla was merely a hack
> to workaround the lack of X compose support in gtk-im-context-simple,
> which is provided through im-xim.so.  Using im-xim.so
> should give us consistent keyboard input for all locales
> across X, GTK, and Qt applications which is a big usability plus
> for users dependent on X compose for writing their language.  

I can only repeat my position on this: 

We need a single input method framework and we need to tighly integrate it with keyboard layout configuration and the rest of the desktop. Tagging input method support onto desktops 'from the side' and trying to make it both 'desktop-neutral' and 'im-framework-neutral' is always going to provide an insufficient user experience.

--- Additional comment from petersen@redhat.com on 2009-11-01 20:30:43 EST ---

I agree wholeheartedly - I see that as a long-term goal
for tight IM integration on the desktop.  I feel
we are gradually moving in the right direction, and
I would like to collaborate on this.

--- Additional comment from petersen@redhat.com on 2009-11-02 04:59:00 EST ---

I built

http://koji.fedoraproject.org/koji/buildinfo?buildID=139343

to help with this issue: please test it with gtk2-immodule-xim
and report any problems or successes here.

--- Additional comment from myllynen@redhat.com on 2009-11-03 11:20:37 EST ---

Thanks Jens, I've now tested your new packages on two test systems and the issue seems to be solved! I'll document some additional details below if someone happens to struggle with this one in the future.

After installing gtk2-immodule-xim and disabling any Input Method (if in use) one just needs to logout and login with an appropriate language and X compose sequences should thenbe in use also in GTK applications. User experience between GTK and non-GTK applications is now consistent.

In practice one can either choose an appropriate (native) language for the whole session at GDM login prompt (like Brazilian Portuguese or Finnish) which will set up LANG environment variable or adjust LC_CTYPE in a shell init script allowing use of a language like US English for the session but still having native compose sequences. The only limitation seems to be that one can't set LC_CTYPE per window basis but needs it for the whole session but I don't think that's a problem, really.

Should there be any issues still checking 'locale´ output might give some clues as well as contents of ~/.dmrc.

--- Additional comment from updates@fedoraproject.org on 2009-11-07 23:54:18 EST ---

imsettings-0.107.4-3.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/imsettings-0.107.4-3.fc12

--- Additional comment from updates@fedoraproject.org on 2009-11-10 12:52:42 EST ---

imsettings-0.107.4-3.fc12 has been pushed to the Fedora 12 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update imsettings'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F12/FEDORA-2009-11244

--- Additional comment from petersen@redhat.com on 2009-11-11 19:32:49 EST ---

Please test and feel free to bump karma in Bodhi to get this
pushed to F12 updates.

--- Additional comment from updates@fedoraproject.org on 2009-11-27 17:02:57 EST ---

imsettings-0.107.4-3.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.