Re: 3.6 Feature: IBus/XKB integration
2012/4/25 Bastien Nocera had...@hadess.net: On Wed, 2012-04-25 at 09:34 +0200, Rui Tiago Cação Matos wrote: On 24/04/2012, Owen Taylor otay...@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 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.6 Feature: IBus/XKB integration
On Tue, May 1, 2012 at 7:12 AM, Giovanni Campagna scampa.giova...@gmail.com wrote: 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. The problem is that xkb uses 2 bits in the core event state mask to communicate the group. That limitation very much affects xkb. A while an xkb2 would be nice, it seems a pipe dream at this point. People have been talking about it for years, nothing ever happened. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.6 Feature: IBus/XKB integration
2012/5/1 Matthias Clasen matthias.cla...@gmail.com: On Tue, May 1, 2012 at 7:12 AM, Giovanni Campagna scampa.giova...@gmail.com wrote: 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. The problem is that xkb uses 2 bits in the core event state mask to communicate the group. That limitation very much affects xkb. A while an xkb2 would be nice, it seems a pipe dream at this point. People have been talking about it for years, nothing ever happened. Yes, I saw that, and that's what I meant when I talked about legacy applications. XInput2 uses 8 bit for the effective group, so it's not limited to 4, and that's what modern toolkits use. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.6 Feature: IBus/XKB integration
2012/5/1 Sergey Udaltsov sergey.udalt...@gmail.com: XI2 does not exactly override XKB, functionally. So there must be some kind of cooperation. I didn't want to imply that. What I meant was that XI2 provides with better and more forward compatible event structures, that allow us to lift the restriction. So, what does happen in xterm when the group number in xinput2 is 5? How should X server be configured in order to provide 5 layouts from xkeyboard-config? Obviously, this should be done on the server side, not on the client side. For events, I'm not sure yet One possibility is to let old XKB behavior (XkbSetControls and GroupWrap) control this for legacy apps (so they would still see only 4 groups), while it would have no effect on new applications. If needed, a new request or event mask can be added to enable the extra groups on XI2/Xkb-aware apps. For keymap manipulation (so the XKB extension proper), I'd say it's not a backward-incompatible change to have XkbGetMap return keymaps with groups higher than 4, and same for XkbSetMap, although that needs testing. The xserver, xkeyboard-config, libxkbcommon, libxklavier, libgnomekbd and other internal libraries will of course need changes, as you for example will be compiling 5 groups instead of 4, but what I'm mostly concerned with it is not adding more protocol, so that applications (as opposed to session components) will work without changes. Giovanni On Tue, May 1, 2012 at 2:00 PM, Giovanni Campagna scampa.giova...@gmail.com wrote: 2012/5/1 Matthias Clasen matthias.cla...@gmail.com: On Tue, May 1, 2012 at 7:12 AM, Giovanni Campagna scampa.giova...@gmail.com wrote: 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. The problem is that xkb uses 2 bits in the core event state mask to communicate the group. That limitation very much affects xkb. A while an xkb2 would be nice, it seems a pipe dream at this point. People have been talking about it for years, nothing ever happened. Yes, I saw that, and that's what I meant when I talked about legacy applications. XInput2 uses 8 bit for the effective group, so it's not limited to 4, and that's what modern toolkits use. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.6 Feature: IBus/XKB integration
I didn't want to imply that. What I meant was that XI2 provides with better and more forward compatible event structures, that allow us to lift the restriction. Noone argues. The xserver, xkeyboard-config, libxkbcommon, libxklavier, libgnomekbd and other internal libraries will of course need changes, as you for example will be compiling 5 groups instead of 4, but what I'm mostly concerned with it is not adding more protocol, so that applications (as opposed to session components) will work without changes. Since the bottom of that issue is x server - I guess would be useful to draft the todo list for it. So other libs would propagate that solution up the stack. Sergey ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
