Re: 3.6 Feature: IBus/XKB integration

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

Hello Sergey,

thanks for your input.

2012/4/24 Sergey Udaltsov <sergey udaltsov gmail com>:
> 1. What about non-gtk apps not having IBus integration? How are they
> going to be supported? Say, good old motif;)

So, gtk+ apps thankfully are able to switch the input method that they
use at runtime just by listening to an XSETTING and I'm doing that
already.

Everything else will continue to work (or not work) as it does now I'm
afraid. The imsettings package in Fedora takes care of setting up some
environment variables according to the user's locale at login time
which should continue to work. Of course any switching the user does
at runtime won't be picked up...

That said, it's my understanding that the IBus developers have a way
to workaround that problem with the XKB simple engines for IBus which
should basically allow us to always direct these "legacy" apps to use
IBus for input and then IBus will just forward the symbols it gets
from the key press events unmodified.

> 1.1. How do you plan to provide network transparency without switching
> layouts on X server level?

The layout is switched at the X server level. The code I have now is
doing the equivalent of running "setxkbmap <layout>" whenever the user
triggers a switch. I don't think network transparency is hindered in
any way here.

> 2. Actually, libxklavier and libgnomekbd are useful not only for
> switching, but for some other things. For example:
>  - (libxklavier) reading xml registry supplied by xkeyboard-config
>  - (libgnomekbd) providing keyboard layout preview
> Are these bits going to be reimplemented from the scratch?

Right, no. The keyboard layout previews I'm planning to do by just
calling the gkbd-keyboard-display utility from libgnomekbd so there's
still a runtime dependency on it for this specific tool.

I don't think we'll need to read the xml registry for anything at this
point. But if the need arises I'll probably just use libxklavier for
that of course.

> 3. How are you going to address the fact that some international
> layouts can be alternatively implemented using XKB and Ibus? Will you
> let user choose? How will you explain him the nature of that choice
> (purely technical detail)?

I'm leaning on just providing a flat list to users on the UI like:

- English (US)
- Japanese

And maintain a table of XKB layouts and IBus engines that each of
those entries translates to. The user won't be faced with arbitrary
choices of layouts, variants, options or IBus engines. We will provide
what's most sensible.

If there's enough demand and it makes sense to add an entry we will do
it. Input from our translators and i18n people on what is popular
enough to make it to that list would be great for this.

> I am all for integration of IBus and XKB, but it is important to make
> it properly, without sacrificing the habits of existing userbase - and
> with proper support of good X11 citizen apps, even if they are not
> blessed by the modern toolkit.

People can still use whatever xmodmap, setxkbmap, etc. hacks they
want. Some of them will even work with this system like for instance
if you just run "setxkbmap -option compose:ralt" on a session startup
script we won't undo that even if you are switching layouts during
that session.

Some things might not work and I'm willing to evaluate how to best
support them on a case-by-case basis. It might very well be that for
some really exotic stuff the answer might be to just disable
gnome-settings-daemon's keyboard plugin in gsettings and then the user
is free to whatever on his own.

Rui