Request for testing: Updated compose sequence functionality in GTK+

Hi All,
That patch from "Bug 321896 – Synch gdkkeysyms.h/gtkimcontextsimple.c with 6.9/7.0",
has been submitted to trunk,

and it is good time to test that not regressions have been introduced.

A. How to try this out?

You can install jhbuild (see, then build gtk+ (jhbuild build gtk+). Finally, open a shell with "jhbuild shell" and run gedit. This will get you gedit with the new, freshly compiled GTK+.

B. What changed?

Two major changes two place; updated list of compose sequences with dead keys (so that your (all?) keyboard layout with dead keys should now work), and updated list of compose sequences that use the Compose key. Currently you can find "documentation" on the additions at;a=blob_plain;f=nls/en_US.UTF-8/Compose.pre
(change the encoding of the browser to UTF-8 once you load the page).

C. How to test?

To test the dead key compose sequences, make sure your keyboard layout supports deads keys. For example, with English (GB), you can get dead keys when you press AltGr+;'#][:@~}{,
That is, you get áŕṕâêûŷĉàäãőűǔǧřẙůǎȧạṭṛẹẉ

When you set a compose key (see posts at, you can try the sequences for Multi_key shown above.

You may need to install more fonts in order to see more exotic characters; for example, if your distribution is not based on DejaVu (Ubuntu uses DejaVu).

D. What I would like people to test?

1. Whether there are any regressions in Win32.
Especially compose sequences that are made of two or more dead keys, as with ΐ (Greek Iota with Dialytika and Tonos). Do things like Compose + (, then 1, then 0, then ) produce ⑩? (that's 10 in a circle) 2. Typical use on different keyboard layouts in order to find any regressions.

E. What is not included in this patch?

This patch does not address compose sequences that produce more than one Unicode codepoint. This is something to work on at a later date, and a different thread.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]