On 24/04/2012, Owen Taylor <otay...@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 _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
