Re: [I18n] Compose files.
Hi, So currently, the Xlib keyboard customization (including compose) all exists on the client side, but the XKB customization (not including compose) exists more on the server side. You want to allow end-users (sitting in front of the Xserver) to be able to configure the compose on the client side. You end up with a similar problem as the Xkb stuff described above, where the client side only has a filename for it's key to the database, but limited ability to send real data. No, those problems are a bit different. First of a client side *has* ability to load a file (as a compiled keymap) into a server. But most important thing is that when one client has chosen right name(s) and sent them to a server and server has found and loaded those files then all clients just get the map from the server independently on where they are running. In this case the server distributes a complete map that is enough for an applications work. But if the server distributes a *name* of Compose file only (and each client has to find and read this file from its local directory tree) there is not guaranty that each client machine has such file. However, Locale Independance sounds like it would be fairly easy to implement and have the added benefit of removing one of the keyboard configuration methods. What do you mean with one of the keyboard configuration methods? I imagine that would reduce the frustration of users. However, I don't totally understand your explaination here: If the result of a compose rule ia a keysym only Xlibhas 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. It seems like you're saying that instead of using a locale, the compose config would be chosen as a result of the keymap chosen. If that's true, that sounds like a great solution to the Locale problem. I didn't mean the compose file will be chosen automaticaly with the keymap choice. I just meant the compose file choice *depends* on keyboard layout choice. And a user will have the same compose rules for different locales (it's quite real situation if one uses C locale for some applications and en_US.UTF-8 for others). Unless per-user customization is really, really pressing, I wouldn't add it outside of the ideal Xkb solution. What do you think? I think I will anyway. :-) -- 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
Re: [I18n] Compose files.
Hi, Vasilis Vasaitis wrote: The second substitution would allow user to add currently used files into own custom Compose file without care where that file is actually placed. No objections here. Just don't forget to add at least another substitution, %%, which produces a literal %, for completeness' sake. Already done. I didn't mention it as an obvious thing. :-) 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. Hm, how about simply checking for the presence of ~/.Xcompose and using it instead of the locale dependent file? In that case, this file would have to include the system wide ones instead of the other way round, so perhaps the substitutions you've proposed wouldn't be really needed. I thought about it. But I think it isn't much better than an environment variable. In one case you have to write a string into your profile file (set the variable) and in another case you have to make a file in your home directory and write some lines there. And both cases are unhandly for configuring utilities. :-( Anyway I can implement both. In this case I think the variable should have bigger priority because if one wants to change compose rules for application only (or apply different rules for different applications) it would be easer to use the environment variable for such task. -- 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
RE: [I18n] Compose files.
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
