Tzafrir Cohen wrote:
> Hi all
>
> Short summary: I see a problem with combining several layouts in the way
> "encouraged by XKB. An example to that problem is the question: how do I
> create a layout of "English(US)+Romanian+Hungarian"
I have almost completed new framework for XKB layouts and thought of
writing rationale. But you have done this part. Thank you.
I have a lot of help requests from people who want layouts with three
alphabets or two ones but with non-US first part (English+Russian+Ukraininan,
German+Russian, Great Britan+Russian, etc.)
What I have done.
First part is patches for a xkbcomp to make it recognize 'an explicit group
specifying'. The modified xkbcomp understands as xkb_simbols strings like
"first_map+second_map:2+third_map:3". There a colon with digit means that
key definitions from the specified map should be shifted to group specified
by digit. Of course, maps there must be keymaps where only one (first)
group described.
It allows use the xkbcomp itself for making keymaps instead of using
editors or scripts.
Note that these changes don't break compatibility with existent scheme
becouse without the 'explicit group specifying' new xkbcomp works like
present one.
As the second part we need provide an adequate representation in
rule/model/layout terms. But keeping compatibility here is more difficult.
On the one hand we need a posibility to specify some layouts for one
'multilayout' xkb_symbols map. But on the other hand I would not like
to change the API for a xkblib (which performs conversion from model/layout/etc.
names to 'xkb components' names). And (maybe more important) until we
make all existent 'layout files' suitable for using them as parts of
multilayout map (maybe never), the xkblib has to distinguish a 'single layout'
specification and specifying layout as part of the multilayout.
So my changes for a 'xkb rule parser' are ...
The XkbLayout can be 'comma separated list' of single layout names, for
example
XkbLayout "us,ru,ua"
(if the list contains names more than 4 all names above this limit will be
simply discarded).
Inside the parser such list is splitted to single names which can be
reffered in the rules file as layout[1], layout[2], etc. For example
! model layout[1] = symbols
pc101 * = base(%m)+%l[1]
....
! layout[2] = symbols
* = +%l[2]:2
Note that layout parts are numbered from 1. Internaly the layout[0] means
'traditional single layout' and also in XKB terms all groups have numbers
from 1.
The compatibility doesn't broken. If the layout name doesn't contain
commas old rules with the 'layout' word will be applied only. Otherwise
(comma separated list) only rules with 'indexed words' (like layout[1])
are used.
There is issue of XkbVariant usage. This name is optional (so can be omited)
and in traditional scheme with only one layout there can be only one
xkbvariant. But since we use some layouts we need some variants were not all
layouts need variants be specified. So in case where only last layout needs
modification we can specify XkbVariants as ",,,nodeadkeys" for example.
(Of course, I have added to rules 'indexed variants' too).
But it looks ugly.
Fortunatly, variants can be specified directly as part of the layout name -
"us, ru(phonetic), ua(winkeys)".
And the third part of work - we need rewrite all layouts map to make them
'single group' symbols maps. I have made few for testing but I don't dare
to offer changes for all existent maps.
Now I'm making last small fixes and I hope I will be able to offer my
work in nearest days.
(The last problem I have met is that a Xserver think itself smarter than the
xkbcomp and carefully filters out all simbols in xkb_symbols name which,
the Xserver supposes, can confuse the xkbcomp. So my non-standard
symbol 'colon' became a victim of this filtering).
> Suppose I want to have a "English(US)-Romanian-Hungarian" layout.
> How do I map this into groups?
>
> (Note: I don't know European layouts too well. What I mean is two layouts
> that each of which is currently mapped into two groups)
Don't forget that the key in each group can have more than two
'shift levels' (up to 64 !). Currently most of maps (except Bulgarian and
Czech) use only two levels in each group. But we can place keysyms that
now occupate an additional group to an additional levels, and assign
to AltGr key an additional modifier (for a third/fourth level shift) instead
of 'group shift' action.
(I guess that 'two levels in two groups' provides better compatibility
for non-Xkb-aware applications. But one who really need multilayout map
can use xkb-aware applications only and, of course, will never switch off
the XKB support.)
--
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
