Re: Updating gtkimcontextsimple.c (bug #321896)

[Simos Xenitellis <simos lists googlemail com>]

Samuel Thibault wrote:
> Samuel Thibault, le Thu 21 Feb 2008 22:01:34 +0100, a écrit :
>   
> > Simos Xenitellis, le Wed 20 Feb 2008 10:04:56 +0000, a écrit :
> >     
> > > What that means is that you need a keyboard layout that produces all
> > > those combining diacritics.
> > >       
> > It looks like you need to buy a non-us-qwerty keyboard.
> >     
Ouch.
> > French keyboards _already_ have a key for the combining circumflex. Be
> > it technically called dead_circumflex or combining circumflex, users
> > don't care, all they want is to see it putting a circumflex on the next
> > typed letter, for instance n̂ (which math people will typically want to
> > type).
> >
> > What you are asking me is to add _another_ key for producing circumflex,
> > so that the french keyboard would have both a dead circumflex and a
> > combining circumflex.  How can the user know which one he is supposed
> > to type (with what you propose, that would mean knowing whether a
> > precomposed form exists in Unicode, which is only about Unicode
> > history)?
> >     
>
> Note: of course, a potential solution would be to just "forget" about
> dead_circumflex and just always use the combining circumflex, but then
> old applications which only know how to deal with dead_circumflex won't
> work any more.
>   
When you say here "old applications", I believe you mean applications 
that will not do proper normalisation.

If you want to have combining diacritics, but have them behave like 
dead_keys (that is, press first the combining diacritics and finally the 
base character), you need to put a restriction on the size of the 
compose sequence (currently 5). This is necessary because the toolkit 
has to store the combining diacritics until the base character is 
pressed (and known); it then emits the base character and finally any of 
the combining diacritics.

Simos