Ivan Pascal wrote:
> The choice of Compose file depends on the current locale and
> is very unflexible.
> The files are placed far from other keyboard-related files
> (many people even
> can't find them). There is not any way to customize them
> (e.g. per-user
> compose file).
>
> I'd like to offer some changes in that mechanism that solve
> at least a part of problems.
>
> First of all I should remind that whereas in many systems a
> composing mechanism
> (dealing with dead_keys and/or Mylti_key like prefix) is a
> part of keyboard
> driver and composing rules are a part of keyboard maps,
Yes, indeed. And that is where they logically belong. It should
be made this way also for XKB.
...
> An ideal solution would be to integrate compose rules into
> XKB (or core
Yes, please.
> protocols) maps but it needs changes in the protocol or a
> making new extension.
> My proposals touch existent files (and compose subsytem) only.
>
> Locale independence.
>
> In existent files a compose rule consists of two parts. A
> 'left side' part is
> a sequence of keysym and a right part (the result of
> composing) is a pair of
> a mylti_byte string and a keysym. Both members ot that pair
> are independed.
> Each of them can be omited and the compose subsystem doesn't check any
> matching between them and doesn't figure out any one of them
> from other.
Ideally, one specifies a sequence(!!) of keysyms that result form
a composition. Each keysym should be translated to text in the
same way a keysym for a "plain" keystroke is translated to (a)
character(s).
Which compose file (using a more XKB-ish syntax inside) to use
should be specified by the keyboard layout; something like:
default alphanumeric_keys xkb_symbols "qwerty-dead_keys"
{
// key-keysym allocation here; and then:
compose euro-latin; // <==== (e.g.)
}
/kent k
_______________________________________________
I18n mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/i18n
