A bunch of additional compose sequences were added to
XFree86 CVS in since gtkimcontextsimple.c was created;
adding these to gtkimcontextsimple should be straightfoward
if a bit tedious.

(Despite what is said in the comments at top of
gtkimcontextsimple, it basically needs to be done
manually. The other thing to know is that the contents
of gtkimcontextsimple.c are "alphabetical" by key symbol
value.. order matters)

Owen, can you send me these perl script (or URL), you have mentioned
in this file comments?

There is no perl script ... that's what I mean, by 
"it basically has to be done manually"

I think those:

The following table was generated from the X compose tables include with
XFree86 4.0 using a set of Perl scripts. Contact Owen Taylor
<otaylor@redhat.com>
to obtain the relevant perl scripts.

After two hours of work I have done only partial revision of
ISO-8859-2. But there are probably much more missing codes. But if it
is not possible, I can finish ISO-8859-2 part manually and let the
rest for others.

Yeah, that comment is wrong:

 - I lost the perl script
 - Even if I hadn't lost it, it wouldn't be useful because
   there has been fairly extensive manual revision after
   the point of the output of the perl script.
   
   (One of the big things I had to do was resolve conflicts.)


I meant to attach earlier the diff of the iso-8859-2 sequences
in XFree86 CVS from the point where the file was originally
generated. I'm not sure that will help you at this point, but
I'll do it anyways since I have it around.

Created attachment 11315 [details] [review]
Unmerged ISO-8859-2 changes

Thank for this file. I will submit update in few hours to HEAD and
gtk-2-0.

The purpose of changes in attachment 11315 [details] [review] was following:
1) Add characters from other charsets.
2) Add sequences for dead_accent+space=accent convention
3) Bug fix
None of them are in relation with gtkimcontextsimple.c.

I have just submitted patch to gtk-2-0 and HEAD.

Reviewing the patch you applied to CVS, found a couple of
ordering mistakes:

   GDK_Multi_key,       GDK_l,  GDK_equal,      0,      0,     
0x00A3, /* POUND_SIGN */
+  GDK_Multi_key,       GDK_l,  GDK_less,       0,      0,     
0x013E, /* LATIN_SMALL_LETTER_L_WITH_CARON */

Ordering here is wrong 

-  GDK_Multi_key,       GDK_C,  GDK_0,  0,      0,      0x00A9, /*
COPYRIGHT_SIGN */
   GDK_Multi_key,       GDK_C,  GDK_less,       0,      0,     
0x010C, /* LATIN_CAPITAL_LETTER_C_WITH_CARON */
+  GDK_Multi_key,       GDK_C,  GDK_0,  0,      0,      0x00A9, /*
COPYRIGHT_SIGN */

The original  ordering was right - '0' is numerically less than
'<'.

Fixed. Can you verify order now?

If you fixed those ones, I'll assume it's OK. (Verification was
done manually)

I have just added also Hungarian characters. Only via dead keys.
Compose combinations in X are buggy and can't be used
(compose+apostrophe+apostrophe generates acute accent, so
compose+apostrophe+apostrophe+o is nonsense), so new convention should
come.

I don't understand the comment about compose sequences - 
we aren't using X at all here to handle compose sequencse.

We don't use them, but GTK Compose sequences are inspired by XFree86
ones. In case of double acute these sequences are buggy, so I have not
added any other - simply I have no idea how to type double acute as
Compose sequence, which doesn't collide with acute Compose sequences.
If anybody has, I will add them.

OT: On my opinion, the best solution should be simple Compose key table:
\' <char> -> <char>_WITH_ACUTE_ACCENT
\" <char> -> <char>_WITH_DIAERESIS
Second part should be Unicode character name parser, which will
generate complete list of all possible dead and compose keyed sequences.

I am adding such project to my project list.

If I will realize it, I will let you know.