Pablo Saratxaga wrote:
> The problem with that is it breaks compatibility for all non-latin
> keyboards where two groups are used.
> Imagine some people has defined his keyboard just as "ru" or "th" etc.
> then he updates XFree86 and those files include only one group --> he
> is unable to type any ascii and can't manage his system anymore...
Sorry, I forgot to mention ...
I don't intend to _replace_ existent layout maps by new ones.
I know that all non-latin layouts are really two-layout maps where the first
layout is 'US qwerty'. And we have to keep all of them at least some time.
For new maps I'd suggest to use a special name extension (for example,
.sg - 'single group') or place them in new subdirectory (for example,
symbols/layouts).
As I said in previous message, a new 'rules parser' distinguish the
'old style' layout specifying (one layout name only) and new one where
more than one layout specified. And it use different rules for these cases.
So it is not problem to use in rules different names or places for new
'single group' maps and for existent ones.
> However, often the first group in such cases is always US qwerty.
> So, what about making those files have an empty first group (that has already
> been done for various keyboard files, it would just need to be done for
> the remaining ones) and then have arule to xkb_simbols that says something
> like:
I would not like to make such kind of changes in xkbcomp.
It is just a compiler. I would not like it have too much intellect to make
assumptions what user meant omiting some part of map.
But I hope we can provide all needed functionality using carefully designed
rules.
> I was thinking about the "phonetic" layouts, their purpose is to allow
> to type a non latin script with a latin keyboard that doesn't have the
> non latin letters printed on the keys.
> They are based on an US qwerty keyboard.
Yes. I thought about differences of latin-based keyboards and problems
it can cause for any secondary layouts.
> For example in a cyrillic phonetic layout the letter with keysyms 'a'
> should sent the cyrillic a, and not the key <AC01>. on an US keyboard
> key <AC01> has the keysym "a", but not on a French keyboard.
>
> Would it be possible to have keyboard groups defined not
> by keyboard layouts (key -> keysms) but by keysym aliasing (keysym -> keysym)
> things like:
>
> a = Cyrillic_a
> A = Cyrillic_A
> b = Cyrillic_be
> ...
I don't know how to assign (in the XKB) a key description to keysym
instead of keycode name. (The xmodmap has such posibility but it seems to me
rather dangerous.)
But the XKB has so called 'keycode aliases' that can help, I suppose.
We can compose special xkb_keycodes files with such aliases ( with
"alias <LATA> = <AC01>" for 'us' keyboard and "alias <LATA> = <AD01>
for French one). And add them by rules like
! layout[1] = keycodes
us = +aliases(us)
fr = +aliases(fr)
...
( By the way, a present rules parser allow to add some partial files in
'options' rules only. I consider this restriction as too strong and
unnecessary. So I have added in modified parser a posibility to use
additions (rules where a right side expression begins from '+' or '|')
in any rules. But we need to be careful with a rules order.)
There still is issue that 'alias originating layouts' must be specified
as first ones. But the same problem we would get using keysym_to_keysym
assignments.
There is another approach - to use 'extended names' of model (pc102_qwerty,
pc104_qwertz, etc.) for aliases choosing. And finally we can combine both
approaches.
--
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
