Re: 3.6 Feature: IBus/XKB integration

[Rui Tiago Cação Matos <tiagomatos gmail com>]

On 24/04/2012, Owen Taylor <otaylor redhat com> wrote:
> I'm worried about performance here as well - when the keyboard layout
> changes, there's a lot of work that has to be done. For GTK+, look at
> the usage of keymap_serial in x11/gdkkeys-x11.c. For Mutter,
> we, among other things may:
>
>  - Get the keyboard geometry and iterate through it to identify
>    the "above tab" key.
>  - Ungrab all keys
>  - Grab all keys again.

Ouch, that looks nasty indeed. Thanks for the heads-up.

> A second issue is that toolkits need to have information about
> not-currently-active layouts in order to handle accelerators properly.
> If my UI language is English, and I have a Russian layout and an English
> layout, then Alt-F should give me the file menu, Control-C should
> copy without regard to the current layout. This is something that was
> a big improvement for users when we implemented it in GTK+.

Didn't know that either.

> 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.

Rui