New composers for local languages in Togo

[Mats Blakstad]

Hei again

Could anyone please explain me how I can flush my composer after I've made
changes to it locally?

Thanks in advance

2016-02-17 0:22 GMT+01:00 Mats Blakstad <mats.gbproject at gmail.com>:

> Thanks again, I've uploaded a new patch now.
>
> I need it to work on Ubuntu 14.04 - I guess that is a GTK application?
>
> I have problems to test on my system. When I update my composer file
> locally, how can I flush & reload new composer?
>
> 2016-02-16 1:07 GMT+01:00 Ran Benita <ran234 at gmail.com>:
>
>> On Mon, Feb 15, 2016 at 07:29:07PM +0100, Mats Blakstad wrote:
>> > There do not exist any precomposed character for these once.
>> >
>> > Does it mean that it is impossible to add these composers for XKB
>> keyboards?
>> >
>> > That's really a big pitty!
>>
>> It is a pity I suppose - Compose is exactly the place where combining
>> characters are likely to be needed.
>>
>> I (personally) also find combining characters more natural to use than
>> dead keys, typing the diacritic after the base character instead of
>> before it (Dead key: ~ + A -> Ã, Combining character: A + U0303 -> Ã).
>>
>> For X/libX11 this is most likely will never be supported, but might be
>> supported in Wayland where there are some extensions to XKB for this
>> use case.
>>
>> All of this said, did you try simply omitting the keysym part, leaving
>> only the string part, and found it insufficient? In the
>> en_US.UTF-8/Compose file, I see many lines which do not specify a
>> keysym, only a string. And from a quick test, xterm and GTK applications
>> both use the string over the keysym. So maybe that's true for all of the
>> applications you care about.
>>
>> > I could of course suggest for unicde to add them as precomposed
>> > charahcters, but would it not be much more easy if XKB could handle
>> > combinations too? Then we don't need to create new unicde characters
>> every
>> > time we want to add a new combinations of tones..
>>
>> My guess is that precomposed characters are for backward compatibility
>> only and new ones will not be added.
>>
>> Ran
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.x.org/archives/xorg-devel/attachments/20160225/a0e82d4e/attachment.html>