Re: 3.6 Feature: IBus/XKB integration

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

2012/4/24 Sergey Udaltsov <sergey udaltsov gmail com>:
> 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?

IBus doesn't define layouts AFAIK. Its engines descriptions contain
XKB layout names that I guess are the ones that work better with a
given engine. For instance the pinyin engine says that the US layout
should be used. So, in your example, xterm would just get the
keystrokes as if they were coming from a US layout keyboard if the
user chose the Chinese (Pinyin) method.

> 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?

No, I don't think xterm supports any kind of input method. xterm will
just work as it works now.

> Ok, that's fair. Except for pure IBus layouts - they cannot be
> configured using setxkbmap, right?

No, IBus only enters the picture if the applications actively support
it. Of course, toolkits like GTK+ usually take up on that job so
individual apps don't have to worry about it. What we do is instruct
IBus to change its current engine when needed along changing the XKB
layout.

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

Well, if you're running GNOME 3 I'd say your computer can certainly handle that.

>> 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?

These aren't changing every month are they? Every once in a couple of
years? I think we can just maintain a list of what's useful on the
GNOME side.

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

Honestly, if a user is locally editing stuff under /usr/share/X11/xkb,
is he our target user? Remember that what I'm trying to do here is
keyboard input configuration be hassle free.

If something is missing that's needed by a relevant portion of users,
of course it will get included.

> So, even if the user would tweak the options using GUI - you keep the
> options specified with setxkbmap at startup, right?

Yes.

> Even if the user
> unchecks/checks "compose:ralt" checkbox?

There's no "compose:ralt" checkbox at the moment. If it's deemed
necessary we will add one (certainly not with that name) and we will
override that specific option then.

Rui