Hello,
There are some issues related to a symbols composing and Compose files that
were mentioned here (and in Bugzilla) during last monthes.
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, in X Window it has
no relations to XKB and its files. Moreover that composing should work if
Xserver and/or Xlib are built without XKB.
The most unpleasant consequence is that Xlib use different ways to get Compose
files and other keyboard-related data. A keyboard map is kept on a server
and Xlib retrives it using XKB protocol (or some core protocol requests) but
Compose file is always read localy from client machine filesystem.
An ideal solution would be to integrate compose rules into XKB (or core
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.
On the one hand it provides a flexibility. The multy_byte string may have no
corrsponded keysym and even be some arbitrary string (a word or even a
sentence). On the other hand it causes problem when user changes a locale.
The string there is exactly what XmbLookupString has to return (without any
changes). Hence for non-ASCII symbols it should be different for C and UTF-8
locales. (Hans Deragon wrote here about the problem he faced: when he changed
a locale to Unicode one, some sequences appeared changed because Xlib used
another Compose file.)
It can be fixed easy. If the result of a compose rule ia a keysym only Xlib
has to convert it to a string according to the current locale in the way used
for usual key press/release events. It this case one compose files can be
used for different locales and depends on a keybord map only.
Customization.
I added to Compose file an 'include' instriction. It allows to compose
Compose file :-) from some files and add small corrections that user prefers.
E.g. if user has custom Compose file it can look like
include "<system wide file>"
my_own_rules
...
Of course, if some rules overlap, Xlib just discards a previous rule and uses
latest one.
Also I think some substitutions in the included file name could be usefull.
A made two ones: %H means the value of HOME variable and %L means the name
with full path to a currently used local-depended file (e.g
/usr/X11R6/lib/X11/locale/iso8859-1/Compose).
The first substitution woild allow to add a per-user preference file into
a 'system' Compose file, e.g.
system-wide file:
common_rules
...
include "%H/.XCompose"
If the file doesn't exist Xlib silently ignores such instruction.
The second substitution would allow user to add currently used files into own
custom Compose file without care where that file is actually placed.
In finally a most doubtfull part: how to specify needed Compose file.
Now I made an environment variable XCOMPOSEFILE which value should be a name
(with a path) of Compose file. But I realize it is unhandly for users.
Any ideas are welcome.
P.S. All changes I'm talking about are already made and tested. I can commit
them in any time. But I'd like to hear suggestions/objections.
--
Ivan U. Pascal | e-mail: [EMAIL PROTECTED]
Administrator of | Tomsk State University
University Network | Tomsk, Russia
_______________________________________________
I18n mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/i18n
