Re: 3.6 Feature: IBus/XKB integration

[Sergey Udaltsov <sergey udaltsov gmail com>]

> It costs in terms of maintenance, certainly. There's exactly one person
> in GNOME that knows libgnomekbd and libxklavier, and that's you.
Well, considering that people submit useful patches to those libs,
there is some shared knowledge. But in general you are right.

> We have the most dreadful options dialogue, with conflicting options[1],
> we have a X server imposed 4 layouts maximum limit[2], server-driven
> keyboard shortcuts with limited options[3].
That's XKB world, right. Something should be done to hide its
"oddities", as everyone agrees. All I am saying is that riches and
flexibility of XKB world should not be lost, if possible. A couple of
notes: [1]I am not sure which options are "conflicting"? [2]As I said
earlier, there can be workaround. Not perfect, but the best you can
do... [3]You cannot avoid that if you deal with server-based group
switching. Well, if you move group switching to the client side, you
can do everything of course...

> We also lacking integration with input methods that a large number of
> users use (and if you want to compare those things, much larger than the
> number of people that use "per window layouts").
+100500.

> There will be small regressions, which we'll do our best to fix, and
> there will be design decisions made to ignore particular problems and
> settings (because I don't see CapsLock key placement as a requirement to
> the free desktop).
Filtering out some options/group is reasonable, even necessary - but
if you are going to keep some of them visible anyway - let's allow
people to turn the filter on/off. Costs nearly nothing, decreases the
unhappiness of the advanced users.

> We need to go forward (and you're merely pointing to problems that we
> didn't know existed because code isn't implemented yet!). I'm sure we'll
> sort those problems out in due time.
Agree!

Sergey