GNOME Bugzilla – Bug 705168
I find no easy way to type ć in gnome
Last modified: 2014-12-08 04:40:51 UTC
I would like to use the compose key to type ć and Ć, using the sequence <multi_key> <c> <acute>, but all I get is ç and Ç. I have a workaround for it, which is to use xim instead of the gtk+ method (adding `export GTK_IM_MODULE='xim'` to my `~/.xprofile`), but I do not find this satisfactory. in particular, I would like to understand the cause of this behaviour. I had opened Bug 694427, but in its wording I suggested an error cause (very probably wrong) instead of stating the nature of the problem. I have tried to understand what is going on here, but I do not manage to find anything that can explain this behaviour, except maybe that the Polish programmers community is smaller than the Brasilian one (for them the current behaviour is highly desirable), but still no place in the code where this substitution takes place. the source code root/gtk/gtkimcontextsimpleseqs.h seems to define the behaviour I would expect, or isn't that file used any more? `xev` KeyPress sequence on <multi_key> <acute> <c> is in both cases (with or without xim): KeyPress event, serial 41, synthetic NO, window 0x4a00001, root 0x94, subw 0x0, time 231308426, (93,50), root:(94,598), state 0x10, keycode 66 (keysym 0xff20, Multi_key), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: -- KeyPress event, serial 41, synthetic NO, window 0x4a00001, root 0x94, subw 0x0, time 231310897, (93,50), root:(94,598), state 0x10, keycode 48 (keysym 0x27, apostrophe), same_screen YES, XLookupString gives 1 bytes: (27) "'" XmbLookupString gives 1 bytes: (27) "'" -- KeyPress event, serial 41, synthetic NO, window 0x4a00001, root 0x94, subw 0x0, time 231311561, (93,50), root:(94,598), state 0x10, keycode 54 (keysym 0x63, c), same_screen YES, XLookupString gives 1 bytes: (63) "c" XmbLookupString gives 1 bytes: (63) "c" -- KeyPress event, serial 41, synthetic NO, window 0x4a00001, root 0x94, subw 0x0, time 231311561, (93,50), root:(94,598), state 0x10, keycode 0 (keysym 0x1000107, U0107), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 2 bytes: (c4 87) "ć" but I must use xim to get ć, otherwise I get a ç. in short, the problem is: within gtk+ there is NO compose sequence that will produce a ć. since there is no workaround within gtk+, I set severity 'major'.
Which gtk+ version is this about?
the one going with the current version of ubuntu (13.04): mario@rune$ dpkg -l libgtk[0-9]* | grep :i386 ii libgtk2.0-0:i386 2.24.17-0ubuntu2 i386 GTK+ graphical user interface library
I hope you tried to use gtk3 and not 2.24. :)
I don't assume it's going to be easy, installing gtk3 in a packaged distribution as is ubuntu. isn't gtk2 mantained any more? but do you mean that it has been solved in gtk3? and do you know what is/was the cause?
I have here a clone of the git repository, just pulled it. I did a checkout of 2.24.17 (the one on ubuntu) and then 3.9.8, in both checkouts I did a recursive grep for 0x00e7 (the ç) the result is exactly the same, (there's some rules associating the sequence GDK_KEY_Multi_key, GDK_KEY_apostrophe, GDK_KEY_c, to it). may I assume you successfully attempted to produce a ć in gtk3?
anyhow, even though I usually work as a software developer, I'm an end user for most of the applications running on my system. I'm sure I misunderstood, but your comment:3 sounds like a hint "wait until all applications have been ported to gtk3". ... as I point out in comment:5, I guess the problem is still there. but is anybody able to confirm this bug report there? please also refer to: https://bugs.launchpad.net/ubuntu/+source/console-setup/+bug/919899 it might help understand _when_ the bug was introduced.
I can confirm this behavior: If I type the key sequence Compose+apostrophe+c, I get ç (c with cedilla) instead of the correct symbol ć (c with acute). I tried it in Firefox and Thunderbird. I am using libgtk 2.24.18-3.17 and 3.8.2-3.20 on Opensuse:Tumbleweed.
same here. behaviour confirmed on Ubuntu precise.
I can confirm this behavior with im-ibus. Problem appears because ibus-1.4.2/client/gtk2/ibusimcontext.c & gtk3/ibusimcontext.c include verbatim copies of imcedilla around line 533. I guess other input methods have been corrupted with the same "fix". Check http://crosbug.com/11421 for details. The main problem here is GTK using a hardcoded table to compose characters. There is no way to have a per-locale translation for key sequences. A few solutions come to my mind (from dirtier to cleaner): * Fix ibus and another input methods so they have a user-defined variable (gconf) to determine cedilla behavior. * Fix ibus and other input methods so only languages that use "imcedilla.so" (from gtk.immodules and immodules.cache) get dead_acute + c = ç. * Fix GTK+ to allow runtime definition of key sequences. Remove imcedilla.so and ccedilla table from all input methods.
with plain en_US keyboard, and no ibus in the picture, compose+'+c works here: ć For ç, I type compose+,+c