2012/4/25 Bastien Nocera <[email protected]>: > On Wed, 2012-04-25 at 09:34 +0200, Rui Tiago Cação Matos wrote: >> On 24/04/2012, Owen Taylor <[email protected]> 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 _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
