GNOME Bugzilla – Bug 116760
dead_acute+ccedilla works differently on GNOME2
Last modified: 2004-12-22 21:47:04 UTC
I have my locale settings set to en_US.ISO-8859-1 and configured my keyboard to use dead keys, and all GTK 1.x, QT and console apps exhibit Ç (C-cedilla) when I press <dead_acute> <C>. However, GNOME2 apps (such as gaim) show ? (C-acute) instead. I find this to be very annoying, and I cannot understand why GNOME2 behaves differently. Is there any specific file I should tweak? Any help will be greatly appreciated. TIA Andre PS: please note this has also been filed on RedHat bugzilla [https://bugzilla.redhat. com/bugzilla/show_bug.cgi?id=88176] and on XFree86 Bugzilla [http://bugs.xfree86. org/cgi-bin/bugzilla/show_bug.cgi?id=122]
*** This bug has been marked as a duplicate of 111334 ***
(I tried to post the comment below to bug #111334, but Opera insists on changing the short_description field because of the special chars used there, which in turn causes Bugzilla to refuse my comment -- ah, the joys of i18n ;) So, I will post it here just to make sure it goes in someplace, please apologize for the confusion) Hi Owen, I am the poster of bug 116760 (marked as a duplicate of this one), and I am most interested in tweaking GTK+/X11/whatever config files to work around this c-cedilla issue. Is it possible at all? Where do I find such gtk+/modules/input files? Also, I would like to confirm that the proposed solution would fit my needs as well: here I use my system configured with LANG=en_US, because I already got used to interacting with the system in English, but I also need to be able to input ISO-8859-1 chars (for example when I am chatting to someone or when I need to write a doc in Portuguese). This will be possible (as it used to be until recent versions), right? Any advice on this? TIA for the help Andre
Andre, I fixed this problem locally by tweaking GTK+ dead key compose sequences (since GTK+ people wouldn't admit inconsistencies with the rest of the world to be a bug). You can edit the file gtk/gtkimcontextsimple.c and change the relevant compose sequences. I'll probably produce a patch that enables dead_acute + c = ccedilla and invalidate some composes (like dead_acute + l = lcedilla), as you pointed up.
[ I do get gtk-bugs@gtk.org mail ] Note that the GTK+ compose sequences are *exactly* consistent with the en_US.UTF-8 compose sequences in this regard. The GTK+ input method modules are in modules/input, and there are several there that extend/change the 'gtkimcontextsimple' method. Once you had such a module, we could make it the default for LC_CTYPE=pt_BR.*, which wouldn't affect the messages you see. Or you can make a specific module current by doing export GTK_IM_MODULE=<module_name> As I think I mentioned earlier, export GTK_IM_MODULE=xim will "fix" your problem if what you want is the standard X compose sequences.
Hi Owen, [ sorry for the duplicate msg, will not happen again ] First of all, please let me tell you that I accept the fact that the described behavior is consistent with UTF-8. What I was trying to understand (and fix) was why it had changed compared to previous RH versions (or, better saying, GTK2 versions). That said, I would like to tell you that the GTK_IM_MODULE trick worked! =) Well, at least, partially: I still relies on the fact that /usr/lib/X11/locale/en_US. UTF-8/Compose is tweaked so that Ç is achieved with <dead_acute><C> instead of <dead_cedilla><C>... is there any more correct way of handling this (I mean: without the need to manually tweak Compose)? Also, exploring your other suggestion: would it help to set LC_CTYPE=pt_BR. ISO-8859-1 on /etc/sysconfig/i18n? Anyway, I am _much_ happier now that I got it working, this will allow me to live with the current setup until a definitive solution comes =) Best, Andre