GNOME Bugzilla – Bug 111334
us-intl keyboard produces c-acute instead of c-cedilla
Last modified: 2011-02-04 16:12:02 UTC
Package: gtk+ Severity: major Version: 2.2.1 Synopsis: us-intl keyboard produces Ä instead of c-cedilla Bugzilla-Product: gtk+ Bugzilla-Component: gtk Description: Description of Problem: 'c should produce c-cedilla, but produces Ä instead. Notebooks don't have AltGr to be able to use AltGr+, c instead. Steps to reproduce the problem: 1. ' 2. c 3. Ä Actual Results: Ä Expected Results: c-cedilla How often does this happen? allways Additional Information: ------- Bug moved to this database by unknown@bugzilla.gnome.org 2003-04-22 05:26 ------- Reassigning to the default owner of the component, gtk-bugs@gtk.org.
The only possible solution here would be to add a special input method with different compose sequences for Brazil... the accented C is a character in various Eastern European languages, and clearly is more natural dead_acute + c than c-cedilla.
> The only possible solution here would be to add a special > input method with different compose sequences for Brazil... > the accented C is a character in various Eastern European > languages, and clearly is more natural > dead_acute + c than c-cedilla. C-cedilla is a character in various Western European languages that are spoken in several Asiatic, African and American countries, including French and Portuguese; it is even (rarely) used in English texts to transcribe French words, such as façade. Shouldn't the behaviour be dependant on LANG, for example producing ç if it is pt, fr, en and their derivatives and ć otherwise? The problem is that one can't rely on the presence of AltGr, which is missing for example on my FireWire iBook -- unfortunately it is sold in various other countries with the US keyboard. This would make it consistent with other OSs as well.
Yes, I know that c-cedilla is used in other languages than portuguese. However, this in practice turns out to be a Portuguese problem and in fact, a Brazillian problem, because the only place that the us_intl keyboard layout is commonly used is Brazil. The French national standard, is a) usable for computer programmers (as I understand the brazillian keyboard isn't) and b) has a separate key for c_cedilla. What I'm proposing by "a separate input method" is basically LANG dependence.
> The French national standard, is a) usable for computer > programmers (as I understand the brazillian keyboard > isn't) I wonder why not... I have used it extensively for all kinds of tasks, including some programming. I work at French-speaking Switzerland, and even here people sometimes fight for US keyboards, being the only one you can reasonably expect to find everywhere if you happen to work, live and travel across language environments... > and b) has a separate key for c_cedilla. So has the Brazilian national standard, but this is about us_intl in keyboards that lack both c-cedilla *and* AltGr. > What I'm proposing by "a separate input method" is > basically LANG dependence. This would be great, when could it be released and working? Any way I could help it happen?
Also, there's some other things that should not happen, i think: 's is producing ś 'r = ŕ 'l = ĺ 'z = ź and 'n = ń This happens only with these characters. The others work as (I) expect, ie: typing 'q produces a beep.
there are various examples of separate input modules in gtk+/modules/input/; many of them derive from GtkIMContextXIM, so would be a decent model for how you would set up a input method to do what you want. As for dead_acute + n => 324, etc, I don't see a problem with that, if what you would normally expect is a beep. There's no reason to forbid an otherwise unused compose sequence.
*** Bug 116760 has been marked as a duplicate of this bug. ***
[ Changing short description since that was causing bugzilla problems for some people ]
I second this bug, because it makes Gtk+2 applications that depends on a lot of input (e.g. Evolution , xchat2) unusable. Gtk+2 Input should have an option to mimic X11's deadkeys behaviour. btw, the "Severity" of this bug should be raised to "critical".
export GTK_IM_MODULE=xim is that option... (And no I'm *not* changing the severity of this to critical, the current behavior of GTK+ is correct, just inconvienient for Brazilian users. And a workaround is available.)
changing to XIM made the problem worse. Now I can't type any accented character. With X11 I type ' + the letter that should be accented and nothing gets displayed. About the "AltGr" + "c" to get c-cedill does not work. It gives me ¢ (which is a c with a | over it, like the cents symbol). c-cedill -> ç is more like an c with a comma (,) in the same place. Right now, for pt_BR with 'us_intl' Keyboards is not just incovenient, but nearly impossible to use gtk2 programs that requires lots of input like evolution and xchat2. Owen, is there any configuration file that would help to show, solve this problem? Also, is there any docs about how to configure a pt_BR 'us_intl' input-method for Gtk+2? If so I could try something. btw, the bug component should be input-methods and not gtk+.
export GTK_IM_MODULE=xim worked for me, but only when using LANG=pt_BR. The problem is that i don't want system messages, menus and everything else in pt_BR. I tried seting only LC_CTYPE=pt_BR, but didn't worked. I want to know if there's something i can do to continue with my system running with en_US lang and be able to type "'+c" to get c-cedilla
I confirm the last comment. With LANG=pt_BR, GTK_IM_MODULE=xim works as expected. However, it does not make sense the dependence of LANG for input.
"However, it does not make sense the dependence of LANG for input" Because it would be better if Xlib magically intuited your language by ...? Note that there are many subcategories of LANG, and it is not necessary to set LC_CTYPE and LC_MESSAGES to the same thing, which I think is the confusion you are having.
>Because it would be better if Xlib magically intuited your >language by ...? Good question. I wipeout every environment variable related to language and locale and ç still work (e.g. gvim). Maybe there is some config file that I am not aware of that holds this configuration for Xlib. Anyway, I am already satisfied with LC_CTYPE=pt_BR and GTK_IM_MODULE=xim (IMHO, this should be the default for Gtk+2). Thank you.
> +export GTK_IM_MODULE=xim is that option... > + > +(And no I'm *not* changing the severity of this to critical, > +the current behavior of GTK+ is correct, just inconvienient > +for Brazilian users. And a workaround is available.) You should. At least confirm the bug. The workaround doesn't work on the Macintosh with pt_BR.UTF-8 at all, especially in the portables that lack AltGr. Please prove me wrong... otherwise I will be forced to purge all my systems from Gtk+ 2.
OK, did some experimentation. The GTK_IM_MODULE=xim workaround works with pt_BR in the LC_CTYPE or LANG variables, LC_CTYPE if defined taking precedence over LANG. But it doesn't work at all if the value is pt_BR.UTF-8. Also, it doesn't work for Gtk+ 1 apps like multi-gnome-terminal. Generalising, I've observed that many Gtk+ 2 apps have broken when presented with a UTF-8 locale, generally just after they get ported from Gtk+ 1. Usually they get fixed after a while, but this bit is still broken. So OK, now we have a working workaround to the workaround. Acknowledgement of the bug, and a permanent fix are still required. I'd suggest unbreaking UTF-8, and restoring the traditional us-intl mapping.
Changing state to NEW, since maybe that's the reason for the worry about "acknowledging the bug"? Note that as far as the GTK+ team goes, we just ignore the difference between UNCONFIRMED/NEW state. Acknowedgement of a bug consists of assigning it to a milestone.
Fri Aug 15 16:54:39 2003 Owen Taylor <otaylor@redhat.com> Improve Cedilla handling - based on a patch from Gustavo De Nardin, #111334 * modules/input/imcedilla.c po/POTFILES.in: Input method that produces C_WITH_CEDILLA rather than C_WITH_ACUTE for dead_acute+c combinations. Make this the default for fr and pt. * gtk/gtkimmulticontext.c (gtk_im_multicontext_get_slave): Use LC_CTYPE instead of LC_MESSAGES to pick the default input method.