[Pkg-ime-devel] Bug#692424: Bug#692424: Bug#692424: ibus: Merge fixes from Ubuntu
On Sat, Nov 10, 2012 at 8:20 PM, Aron Xu <happyaron.xu at gmail.com> wrote:
> GNOME 3.6 can live with older version of ibus if you don't enable the
> compile time integration, and currently the integration makes input
> experience gets downgraded heavily, it's highly recommended not to enable it
> at least for this cycle.
In theory you're right.
In practice I doubt it.
I guess Ubuntu 12.10 is indeed GNOME 3.6 without IBus integration.
However, IBus 1.4 doesn't work in this environment; no tray icon at all.
I guess it's because GNOME Shell in 3.6 block old school GtkStatusIcon.
(GTK3 UI of IBus is only available in 1.4.99)
( I end up use GNOME Fallback to see the tray icon, SO SAD. Fallback
will be dropped in GNOME 3.8)
> Reasons behind are the integration hides most input method engines in ibus
> that GNOME developers think useless, they believe that only a small number
> of high quality engines will be able to handle all the users' needs, while
> most of them have never tried a input method, not mentioning how users
> depend on the existence of many many different engines that they never heard
> about.
Actually I believe that a desktop system should offer input
functionality for all languages regardless of UI language; that's the
most friendly to users.
We cannot archive this before because IMF and XKB covers different
language groups. Even modern IMF can handle XKB, XKB using people
don't want to switch to IMF. My claim is from a thread in kde-devel.
http://lists.kde.org/?l=kde-devel&m=134081368017885&w=2
So I agree with the high level idea of GNOME integration, but the
implementation detail has many stuff to be improved.
> Another reason is when you have the integration enabled and ibus-daemon
> available, any other input method framework will not work because
> gnome-settings-daemon will continusly reset the input method related
> variables and try to start ibus. In this case nether the alternative input
> method framework nor ibus can behave normally.
I think this is the desirable behaviour. This eliminates the need of
manual of distribution specific configuration before one can really
use IBus.
g-s-d used to set environmental variables blindly. Then Weng made a
already merged patch that check whether ibus-daemon is in PATH.
I guess we can go a little bit further that g-s-d should check a
configuration key before it check whether ibus-daemon is in PATH.
Reply to: