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

[Osamu Aoki]

Hi,

On Fri, Nov 23, 2012 at 07:09:05PM -0600, Ma Xiaojun wrote:
> On Fri, Nov 23, 2012 at 6:40 PM, Jeremy Bicha <jbicha at ubuntu.com> 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.

As I recall previous GNOME imput method selection dialog, there were a
user configurable short list which showes up in selection list directly
from icon.  The master list was based on all installed methods.  We can
follow their new whitelist as the default shortlist filter but someone
has to write extra code for configuring this short 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
> altogether?

Thst is impossible.  What if someone add customized table etc. as
extension.  It needs to be supported.

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

Good idea.

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

If ibus 1.5 (1.4.99 is prerelease of 1.5) comes out, we may still need
to consider which compilation option to enable so we may keep
more-or-less 1.4 like behaviour...

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

If someone write that section of gnome-shell pluggable with many input
method, I will be happy to update im-config to support it.

At least im-config need to change its default for GNOME to no-IM and
other desktops to cjkv(for Ubuntu) 

After new post-freeze Debian im-config fix induced by Ubuntu comment, I
am wondering if new GNOME ibus handles such programs started by dbus
well or not.  Are they tweaking not just ibus related process and
environment variables but dbus ones within gnome-shell.  I am curious
and searching for answer...

Osamu