Annoying GNOMEism, again (was: Update on the new ibus-1.5 and gnome-settings-daemon gnome-control-center 3.6 situation)

Ma Xiaojun damage3025 at
Sat Nov 24 01:09:05 UTC 2012

On Fri, Nov 23, 2012 at 6:40 PM, Jeremy Bicha <jbicha at> wrote:
> It's very easy for Ubuntu as a distro to change a gsettings default
> (that's what ubuntu-settings and ubuntu-gnome-default-settings do).

Well, show_all_source won't be a good option since it would show some
useless engines either. The only thing I can think of is patch the
white listing code directly and effectively change it a black list.

> And it doesn't sound like it would be too difficult to patch
> gnome-shell to support a few more ibus properties.

Are you going to check all engines in main and universe and add them
Then why we need to do this in the first place?
Such filtering would also handicap users installing engines we don't
know or developers
working on new engines.

> But for now, we don't have to worry too much about either of those
> concerns since I believe there's universal agreement that Ubuntu
> should stick with ibus 1.4 until the other concerns are addressed (at
> the least, support for separate layout per window and incompatibility
> with non-ibus input methods).

Probably you believe that IBus 1.4.99 just do some internal change and
has little goodies to users. Probably not. If we have IBus 1.4.99 we
can have newer IBus engines and they should be improved by definition.
I can give you a list:
We can have ibus-pinyin 1.4.99 instead of 1.4.0
We can include ibus-libpinyin now
We can have ibus-anthy 1.4.99 instead of 1.2.7
We can have latest ibus-chewing (it probably compatible with 1.4 either)
And naturally, the upstreams take care of their git versions, rather
than old versions.

For 'support for separate layout per window', I wonder how would it
happen if we do nothing now. Even if we managed to do it in IBus
level, I guess it won't help that much. Because in g-c-c is the master
program controlling IBus and XKB. The worst case can be that we patch
g-c-c code. But IBus may not need any change.

I don't know 'incompatibility with non-ibus input methods' means what.
If you mean the Nux bug, it is unrelated at all.
If you mean usability of non-IBus input frameworks under GNOME Shell.
I guess the best thing we can do is add a hidden gsettings key that
control whether IBus integration is enabled. Currently they detect
whether ibus-daemon is in PATH.

More information about the ubuntu-desktop mailing list