Re: 3.6 Feature: IBus/XKB integration

[Giovanni Campagna <scampa giovanni gmail com>]

2012/5/1 Sergey Udaltsov <sergey udaltsov gmail com>:
> XI2 does not exactly override XKB, functionally. So there must be some
> kind of cooperation.

I didn't want to imply that. What I meant was that XI2 provides with
better and more forward compatible event structures, that allow us to
lift the restriction.

> So, what does happen in xterm when the group number in xinput2 is 5?
> How should X server be configured in order to provide 5 layouts from
> xkeyboard-config? Obviously, this should be done on the server side,
> not on the client side.

For events, I'm not sure yet One possibility is to let old XKB
behavior (XkbSetControls and GroupWrap) control this for legacy apps
(so they would still see only 4 groups), while it would have no effect
on new applications. If needed, a new request or event mask can be
added to enable the extra groups on XI2/Xkb-aware apps.
For keymap manipulation (so the XKB extension proper), I'd say it's
not a backward-incompatible change to have XkbGetMap return keymaps
with groups higher than 4, and same for XkbSetMap, although that needs
testing.
The xserver, xkeyboard-config, libxkbcommon, libxklavier, libgnomekbd
and other internal libraries will of course need changes, as you for
example will be compiling 5 groups instead of 4, but what I'm mostly
concerned with it is not adding more protocol, so that applications
(as opposed to session components) will work without changes.

Giovanni

> On Tue, May 1, 2012 at 2:00 PM, Giovanni Campagna
> <scampa giovanni gmail com> wrote:
>> 2012/5/1 Matthias Clasen <matthias clasen gmail com>:
>>> On Tue, May 1, 2012 at 7:12 AM, Giovanni Campagna
>>> <scampa giovanni gmail com> wrote:
>>>
>>>
>>>>
>>>> So, assuming this is indeed a limit that we want to fix, why not
>>>> fixing at the right level, i.e. Xorg?
>>>> I recently looked at the Xkb and XI2 protocols, and I saw no
>>>> particular limitations to using more than 4 groups (up to 255, which
>>>> is a much more reasonable limit). There is indeed a limitation in the
>>>> core protocol, but that's only used by legacy applications.
>>>> In any case, I believe this discussion should be moved to xorg-devel,
>>>> as the proposed solution (setxkbmap equivalent) not only has
>>>> performance regressions, it will also cause problems with keybindings
>>>> in non-latin layouts, as applications will no longer have another
>>>> latin group to fallback on.
>>>
>>> The problem is that xkb uses 2 bits in the core event state mask to
>>> communicate the group. That limitation very much affects xkb. A while
>>> an xkb2 would be nice, it seems a pipe dream at this point. People
>>> have been talking about it for years, nothing ever happened.
>>
>> Yes, I saw that, and that's what I meant when I talked about legacy
>> applications. XInput2 uses 8 bit for the effective group, so it's not
>> limited to 4, and that's what modern toolkits use.
>> _______________________________________________
>> desktop-devel-list mailing list
>> desktop-devel-list gnome org
>> http://mail.gnome.org/mailman/listinfo/desktop-devel-list