Re: 3.6 Feature: IBus/XKB integration

[Sergey Udaltsov <sergey udaltsov gmail com>]

Hi Rui

> 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...
My question was about layouts that are implemented through ibus, but
not xkb. For example, if user chosen Chinese IBus layout - what's
going to be entered into xterm? Will XKB layout be "converted" on the
fly from IBus layout?

> 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.
Err, I am not sure I understand the process completely. Does that mean
IBus sets up some "proxy" that converts X events before they reach
xterm?

> 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.
Ok, that's fair. Except for pure IBus layouts - they cannot be
configured using setxkbmap, right? 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...

> 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.
Fine.

> 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.
How are you going to find out what layout are available from XKB?

> 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.
I am opposite to that. If the user adds layout/variants to
xkeyboard-config, he wants these layouts to be available. I already
have bug reports about not showing "extra" (more exotic) layouts - but
at least that is switchable with a single gsettings key. I am trying
to be sensible in separating "core" from "extras" - but at least if
something managed to get into "core" - it is visible immediately.
Neither libxklavier nor libgnomekbd nor g-c-c filters those materials
- all filtering is done in xkeyboard-config (and it is easy to switch
on/off). By putting extra filter, you make the process more difficult
- people will have to change two places, xkeyboard-config and your
code (will it be compiled-in or put into some xml file?). The process
becomes not transparent.

> 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.
So, even if the user would tweak the options using GUI - you keep the
options specified with setxkbmap at startup, right? Even if the user
unchecks/checks "compose:ralt" checkbox?

Regards,

Sergey