Re: X Strike Force XFree86 SVN commit: r1832 - in trunk/debian: . local
On Mon, Sep 20, 2004 at 03:04:09PM -0500, X Strike Force SVN Repository Admin wrote:
[...]
> -<p>In releases previous to XFree86 4.3, combining several keymaps was
> -difficult because keymaps had to be defined for each position. For instance
> -<code>us</code> keymap was defined on first, second and third position,
> -and this should have been done for all keymaps.</p>
> +<p><em>Thanks to Denis Barbier for contributing this entry.</em></p>
>
> -<p>Keymap layouts have been revisited in XFree86 4.3, and new definitions
> -can now be used in whatever order so that <code>us,ru</code> and
> -<code>ru,us</code> use the same definitions. New definitions have been put
> -into <code class="filespec">/etc/X11/xkb/symbols/pc/</code> and old ones are
> -still available at the same place, ie. under the
> -<code class="filespec">/etc/X11/xkb/symbols/</code> directory,</p>
> +<p><em>[TODO: This entry needs to be more careful with "keymap" versus "layout"
> +terminology.
True, I will try to improve wording here.
> Also, I don't understand the first paragraph or the first sentence
> +of the second paragraph. Do the mentioned "positions" have to do with shift
> +levels? Also, what relationship do shift levels have with groups? —
> +BR]</em></p>
No, in my bogus terminology, position means the group number.
I wanted to tell that /etc/X11/xkb/symbold/us_group{2,3} were defined
to allow 'us' layout in 2nd or 3rd group, e.g. 'ru+us' layout is achieved
by combining 'ru' and 'us_group2'.
With this syntax, 'us+ru' needs 'us' and 'ru_group2' layouts (the latter
does not exist), so it is clear that all layouts need several
definitions, one for each group number. Comparing us_group2 and
us_group3 shows that this is ridiculous.
With the new layout format introduced in XFree86 4.3, layout definition
does not depend upon group number, so 'us+ru' and 'ru+us' use the same
symbol files.
Unfortunately, some layouts were not converted to this new format, and
can not be combined with other layouts.
BTW I had a look at capplets and gnome-applets bugs, and several of them
complain that trying to add these layouts does not work. Unfortunately,
these applications cannot easily fix these bugs, so I am going to
reassign them to xlibs.
In fact, xlibs can ship most (if not all) of those layouts in the new
format to help users who do need them, without any breakage.
The idea is to keep 099z_xkb_fix_rules_xfree86.diff unchanged so that
$oldlayouts in rules/xfree86 lists all layouts which are currently
shipped by xlibs in the old format, and get new symbol files from xorg
(more specifically from xkeyboard-config) into symbols/pc/.
With this setting, the layout is loaded from symbols/<foo> for the first
group, and from symbols/pc/<foo> for all other groups.
There is no breakage with single layouts because the same files are
loaded, and multiple layouts are allowed for these layouts.
Denis
Reply to: