GNOME Bugzilla – Bug 689070
Add a GSettings Key to Make non-IBus Users' Life Easier
Last modified: 2012-11-30 06:57:59 UTC
Source code hint: http://git.gnome.org/browse/gnome-settings-daemon/tree/gnome-settings-daemon/main.c#n276 It detects whether 'ibus-daemon' is in PATH currently. If we add a gsettings key also, users don't have to remove IBus to disable IBus integration. There are at least two reasons for that. 1. Sometimes GNOME depends IBus directly, so removing IBus is not an option. This is not hypothetical, it happened and the distribution concerned disabled IBus integration finally. https://bugs.archlinux.org/task/32071 2. Removing IBus is cumbersome for multi-user environment, e.g., organization deployment, since different users can have different preference over IMF.
Sorry but no. I feel like we already provide enough knobs to disable ibus usage both at build time and run time. If we start adding random settings like this, next time someone asks for a setting to disable e.g. systemd support what would we say?
> Sorry but no. I feel like we already provide enough knobs to disable ibus usage > both at build time and run time. A run time configuration that requires root privilege and file / package removing is certainly cumbersome. If you do provide run time configurability, then provide it in a sane way. > If we start adding random settings like this, next time someone asks for a > setting to disable e.g. systemd support what would we say? You can mark that bug as WONTFIX and replace systemd with another random name.
According to your documentation: https://live.gnome.org/ThreePointFive/Features/IBus#How_to_use_other_IM_frameworks XKB integration can be turned off by a gsettings key. $ gsettings set org.gnome.settings-daemon.plugins.keyboard active false But IBus integration has to be turned off by removing ibus-daemon. What's the point here?
(In reply to comment #3) > According to your documentation: > https://live.gnome.org/ThreePointFive/Features/IBus#How_to_use_other_IM_frameworks > > XKB integration can be turned off by a gsettings key. > $ gsettings set org.gnome.settings-daemon.plugins.keyboard active false That disables *both* XKB and IBus handling. > But IBus integration has to be turned off by removing ibus-daemon. XKB isn't pluggable...
> That disables *both* XKB and IBus handling. Well, as far as I can see, that ( gsettings set org.gnome.settings-daemon.plugins.keyboard active false ) doesn't prevent set_legacy_ibus_env_vars() in g-s-d. The result, as some people tried, is that without removing ibus-daemon you cannot use alternative input method framework in non-GTK applications. My origin request is certainly invalid now since I misunderstood the semantic of that key. Now I'd request that set_legacy_ibus_env_vars() should respect that key also. > XKB isn't pluggable... IBus isn't pluggable either from non-root users' point of view. Anyway, I haven't seen the point. Because there is a workaround (removing ibus-daemon) so you are fine with something inconsistent (a setting seems to disable both integration but in fact it disable XKB integration completely and leaves IBus integration in a tricky state) ?
Created attachment 230259 [details] set_legacy_ibus_env_vars() doesn't respect 'that' key
You've found a bug, which is now fixed. commit 3c23552d9d73e45319742f80e250375d7a8eac13 Author: Bastien Nocera <hadess@hadess.net> Date: Fri Nov 30 07:38:19 2012 +0100 main: Don't set IBus envvars if keyboard plugin is disabled https://bugzilla.gnome.org/show_bug.cgi?id=689070
Thank you very much!