Re: 3.6 Feature: IBus/XKB integration
- From: Giovanni Campagna <scampa giovanni gmail com>
- To: desktop-devel-list <desktop-devel-list gnome org>
- Subject: Re: 3.6 Feature: IBus/XKB integration
- Date: Tue, 1 May 2012 13:12:29 +0200
2012/4/25 Bastien Nocera <hadess hadess net>:
> On Wed, 2012-04-25 at 09:34 +0200, Rui Tiago Cação Matos wrote:
>> On 24/04/2012, Owen Taylor <otaylor redhat com> wrote:
> <snip>
>> > So, I don't think it really works to just ignore the group mechanism of
>> > XKB and always load a one-group layout... it makes more sense to me to
>> > identify what layouts are needed for all the input sources and load them
>> > into a single keymap ahead of time. Yes, that might limit the user to
>> > switching between 4 languages, but, really, how common is it to need
>> > more than that?
>>
>> Ok, that sounds like the best way forward then. And yes, I agree that
>> users don't need to switch among more than 4 languages.
>
> The 4 layouts limit is an artificial limit that causes bug reports and
> raised eyebrows, and was one of the bugs that the ibus/xkb integration
> was supposed to fix. Missing out on it would be a great
> disappointment...
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.
Giovanni
[Date Prev][
Date Next] [Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]