Several compose key combinations don't work

This bug is still present in Feisty. Please give it a high priority! It's very frustrating having to learn a Turkish keyboard layout simply to enter a g-breve. The problem is a regression because the sequences used to work in xfree86/x.org (for instance they were working in the Gentoo installation I was using last year.

I have just discovered that there are two problems here.

One is that compose key combinations are not what they were. For instance I used to use [ gu ] for a g-breve (as per http://docsun.cites.uiuc.edu/sun_docs/C/solaris_9/SUNWdev/I18NDG/p25.html etc.), but now it is [ Ug ].

The other problem is that some compose key combinations work in some applications but not others.

For instance [ ss ] for ß works in all the applications I have tried it in, whereas [ Ug ] for ğ works in Konqueror, Kate, Konsole, LyX, OpenOffice (i.e. openoffice.org-kde; openoffice.org-gnome might possibly behave differently) and Opera, but not in Gedit Firefox, or Gxine. I think this is a gnome/gtk thing (which would also explain why it doesn't work in Abiword or SeaMonkey) because I read somewhere that gnome overrides some of the compose key functionality for some reason. I also read that if you append

export GTK_IM_MODULE = "xim"

to your /etc/environment, this will disable the gnome override. However this doesn't work for me.

I am actually a KDE user, but the GTK applications misbehave like this anyway.

I have just discovered that there are gnome compose key sequences for probably all the characters the normal compose key sequences cover. They are listed at https://help.ubuntu.com/community/GtkComposeTable.

The trouble has been that it has taken me many many hours to discover this. And even then I still have the task of learning a whole new set of control key combinations.

Therefore I think the real bug is that:

- the existence of gnome compose key combinations is not signposted at all (let alone clearly signposted) even when you are using Gnome. And even if it was, this would not help you if you were calling gnome applications from within kde.

- The method given at https://help.ubuntu.com/community/ComposeKey for choosing to use the standard X11 compose key sequences in Gnome doesn't work.

- Even if it did work, there is no gui method for selecting it, not within Gnome, nor KDE, nor any other desktop environment.

I'd also like to note that the GNOME compose table appears to lack a mapping to give open and close double quotes, though it does have open and close single quotes.

I just used the method described in https://help.ubuntu.com/community/ComposeKey on my Gutsy system, and it does appear to work. GTK applications now use the same Compose map as non-GTK applications. Is there any reason not to make the xim input module not the default?

Seems to be a wishlist item rather than a bug.

So, is there any official decision made about which system Ubuntu should adhere to? The X11 compose sequences, or the Gnome/GtkComposeTable. Or is GTK just being followed, because Ubuntu uses Gnome per default...

Choosing GtkComposeTable obviously confuses some users. It also seems less complete, but perhaps some sequences in it are more straightforward than in the X11 counterpart.

Using GtkComposeTable in GTK applications confuses some users, because compose sequences then work differently depending on the application's GUI framework. A kind of low-level distinction of applications, that I believe the general user not should need to make. Shouldn't it work the same way everywhere?

Daniel, I agree with you that it should work the same for the user on all applications, but I'm not sure who is responsible for making this sort of decision. This is, in my opinion, against the Ubuntu design principle of "There should be exactly one recommended way to accomplish a task".

Using GtkComposeTable would be fine with me, if the missing characters were included (I'm missing lower opening and upper closing double quotes most desperately). In the current state I would consider this a bug, and I would appreciate any suggestions for disabling this behaviour.

mkluwe:

  A quick fix for that seems to be to put the following into ~/.gnomerc:

      export GTK_IM_MODULE="xim"

  GTK will then use the X11 compose sequences, which has <less> <,> and <greater> <">, that you want.
  See: https://help.ubuntu.com/community/ComposeKey

Though someone metioned that this didn't work for him, it did for me. Thank you for the hint.

Not with Firefox, but with other applications such as gedit and
gnome-terminal, there *is* a graphical way to change your input method
temporarily to the X input method. Right-click (if your pointing device is
set for right-handedness :^]) in the text input field, and choose Input
Methods and then X Input Method (or Input Methods and then System to return to
the GNOME input method). With the X input method, if your locale allows it,
you will be able to enter “ (LEFT DOUBLE QUOTATION MARK) by tapping
Compose·<·" (or Compose·"·<), but you won’t be able to enter it by tapping
Ctrl+Shift+U·2·0·1·C·Space. This setting will persevere for this one
application session.

If there is a need to standardise Compose key sequences, perhaps this could be forwarded to or taken up by freesdesktop.org?

I had some troubles with c cedilla (like Ç, instead Ć). In Brazil we type ' + c (acute plus c) to do ć. But when running Firefox32 with Kubuntu 64 bits, GTK fails to load the 32 bit cedilla IM module. GTK always load the 64 bit module version.
I workaround it changing the internal references to the string "cedilla" from the im-cedilla.so 32 bit version to "cedil32" and setting the environment variable GTK_IM_MODULE to cedil32 (only to Firefox32 - I change its script). Also I include the im-cedil32.so into the 64 bit GTK IM module configuration file:
/usr/lib/gtk-2.0/2.10.0/immodule-files.d/libgtk2.0-0.immodules
I include the following two lines:
"/usr/lib/gtk-2.0/2.10.0/immodules/im-cedil32.so"
"cedil32" "Cedil32" "gtk20" "/usr/share/locale" "az:ca:co:fr:gvct:sq:tr:wa:en:us"

Now after many search and trying, I can type '+c to get ć

More details at:
http://www.marciowb.net/blog/2008/07/c-acentuado-vs-c-cedilha-no-firefox32

Regards,
Marcio Wesley Borges
http://www.marciowb.net/blog

Also bitten by this one. GTK_IM_MODULE="xim" fixes the problem.

Appears for me on Intrepid, GTK_IM_MODULE is scim-bridge. Setting it to xim removes compose key support completely. However, the bug wasn't present on this system when using Ubuntu Hardy, and is hence a regression.

Setting GTK_IM_MODULE="xim" worked well on Ubuntu 8.04. Wish it was the default setting, to make the GTK applications consistent with everything else.

The compose tables should be unified, also with the Linux virtual console compose tables. The compose mechanism is a very powerful one, and this schism is contra-productive.

I should not have to think carefully before I can type my own surname.

could somebody try on jaunty and send it to bugzilla.gnome.org?

Running Jaunty 9.04, fully updated as of Monday 18 May 2009.

The Gnome project's decision to implement an unannounced (to the end user) separate compose key list shows mind-bogglingly poor judgment.

As Jan Minář notes, compose is a powerful mechanism, and quite simple and easy to use as well. Gnome's alterations to this mechanism are confusing and counterproductive, and the GTK compose key list is incomplete in addition to being needlessly inconsistent with the original X11 compose key lists.

For instance, Gnome for some unfathomable reason decided not to implement a/A or o/O with a macron. Following the X11 compose sequences for these, <Compose key> + - (hyphen) or _ (underscore) + a/A or o/O instead produces the same output as <Compose key> + ~ (tilde) + a/A or o/O. *Why* in the devil's briefcase did anyone think it makes sense to remove functionality in order to duplicate an already-extant separate key sequence? This oversight and apparent arrogance actually angers me.

This would not be such an issue if it were possible to edit the compose key lists used by GTK -- but although the X11 lists can be edited, this is apparently *not* possible for GTK:

     "The ComposeKey sequences used by Gnome to enter special characters are hard coded into the program."
     (from https://help.ubuntu.com/community/GtkComposeTable)

*Why* hard-code these sequences? Being able to edit them is very useful, and this is precisely why these sequences are editable for X11. Yet Gnome seems to be following the same "we know better than you" mentality evinced by the much-despised Microsoft.

-----

Setting GTK_IM_MODULE="xim" does *NOT* work usefully on my machine. It does prevent the Gnome compose key sequences from working, but it also means that my compose key settings in System -> Preferences -> Keyboard -> Layout Options are also ignored. Due to my keyboard (a Dell multimedia version, no right Win key, for instance), I therefore cannot seem to find the X11 compose key, and setting the XkbOption as described at https://help.ubuntu.com/community/ComposeKey does not seem to work (I do log out and restart the X server each time I change settings, so that's not the issue). Consequently, I can either use Gnome's incomplete and confusing compose key options, or none at all. This is completely unacceptable.

-----

I thought the whole point of the freedesktop.org initiative was to *unify* desktop functionality. Gnome's go-it-alone approach with how the compose key works is incredibly frustrating. I will definitely be posting to bugzilla.gnome.org.

Did my best to report on this issue. It sounds like Gnome is struggling to integrate older compose key sequences with the X11 lists, and these bugs are cropping up due to list disagreement. Judging from the bug report discussion, hopefully these issues will be shaken out before too much longer.

More details at:

http://bugzilla.gnome.org/show_bug.cgi?id=557420

Why is this bug set as "Fix Released"?
I'm using version 2.21.2-0ubuntu3 of gtk+2.0 (from maverick), and the Compose-O-- sequence still gives an Õ instead of an Ō, as Eiríkr Útlendi posted above, so apparently this bug is still present.

you can read the upstream bug for details

upstream considers this issue fixed, if you still have things not working in lucid open a new bug