GNOME Bugzilla – Bug 565912
Improve compose key functionality
Last modified: 2010-10-30 09:59:21 UTC
Please describe the problem: When activating the compose key, e.g. to the windows keys, the functionality regarding the input order has decreased compared to earlier version of GNOME. The input order used to be irrelevant for creating characters with diacritics like é (small e with acute accent). It was possible to do compose->'->e or compose->e->' and both would result in the same. Now, only compose->'->e is working. The import order is much wider used because it is also used like this in our natural language. People talk and think about an 'e' with a certain accent, it should be possible to enter it like that and it is much brain friendlier. I don't know that the reason is for allowing only one input order sequence, perhaps to double the possible compositions that can be made. For adding diacritics (and preferably for all compositions) I would like to request that the compose key functions regardless the input order or at least turn it around for the diacritics. Improving compose key like this allows for higher user satisfaction when entering characters with diacritics in an easier way. If this functionality is part of another component inside or outside GNOME, please let me know and I will report it there. Steps to reproduce: 1. 2. 3. Actual results: Expected results: Does this happen every time? Other information:
Should this be reported for the libx11-data package or is this part of GNOME?
What is the input method you are using? There is basic Compose support in gtk, also there is XIM, there is SCIM. Do you see that degradation in non-gtk apps?
bug should belong, and is reported, here: http://bugs.freedesktop.org/show_bug.cgi?id=19378
Reopened because GNOME / GTK has its own Compose functionality. This bug belongs in GNOME and in XORG, see also http://bugs.freedesktop.org/show_bug.cgi?id=19378
More info on GNOME compose table can be found here: https://help.ubuntu.com/community/GtkComposeTable