After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 565912 - Improve compose key functionality
Improve compose key functionality
Status: RESOLVED FIXED
Product: gnome-control-center
Classification: Core
Component: Keyboard
2.24.x
Other All
: Normal normal
: ---
Assigned To: Control-Center Maintainers
Control-Center Maintainers
Depends on:
Blocks:
 
 
Reported: 2008-12-29 08:19 UTC by Pander
Modified: 2010-10-30 09:59 UTC
See Also:
GNOME target: ---
GNOME version: 2.23/2.24



Description Pander 2008-12-29 08:19:06 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:
Comment 1 Pander 2008-12-29 08:50:23 UTC
Should this be reported for the libx11-data package or is this part of GNOME?
Comment 2 Sergey V. Udaltsov 2009-01-01 23:49:59 UTC
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?
Comment 3 Pander 2009-01-03 16:33:55 UTC
bug should belong, and is reported, here:

  http://bugs.freedesktop.org/show_bug.cgi?id=19378
Comment 4 Pander 2009-01-04 02:48:25 UTC
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
Comment 5 Pander 2009-06-30 20:55:50 UTC
More info on GNOME compose table can be found here:
  https://help.ubuntu.com/community/GtkComposeTable