On Tue, 2012-04-24 at 17:56 +0200, Rui Tiago Cação Matos wrote: > > And, of course, there is a question > > of performance - invoking setxkbmap (even calling corresponding XKB > > APIs) is so much more expensive than changing current group in X > > server... > > Well, if you're running GNOME 3 I'd say your computer can certainly handle > that.
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. 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+. 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? - Owen _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list