GNOME Bugzilla – Bug 747825
Fcitx not work in terminal, nautilus, gedit
Last modified: 2015-04-18 10:44:31 UTC
Distribution: Arch linux `uname -a`: Linux xbull 3.19.3-3-ARCH #1 SMP PREEMPT Wed Apr 8 14:10:00 CEST 2015 x86_64 GNU/Linux After upgrading to Gnome 3.16, fcitx not works in gnome-terminal, nautilus and gedit (cannot switch to non-English input method), but still works in Firefox, Activities Overview. Even after reinstalling Arch linux, the problem exists. Post in Arch forum: https://bbs.archlinux.org/viewtopic.php?id=196069 Someone has found a workaround: run applications through Alt + F2. It works for nautilus and gedit. As for gnome-terminal, open Alt + F2 twice and run one line of code at a time: /usr/lib/gnome-terminal/gnome-terminal-server --app-id my.test.terminal gnome-terminal --app-id my.test.terminal
Changed the product from gtk+ to gdm, since some other found that using kdm and lightdm to start Gnome would not meet the problem. It should be a bug of gdm 3.16.0. Before gdm solves the problem, there are three workarounds now: 1. Run applications through Alt + F2 2. Use kdm, lightdm or other display managers instead of gdm 3. Downgrade gdm to 3.14
Not only fcitx, I also tried gcin, and got the same result. GNOME Applications launched by DBus(GApplication service mode) can't get the environment variables of input method(GTK_IM_MODULE, QT_IM_MODULE, XMODIFIERS), I guess that is the reason. Downgrade gdm to 3.14 is a simple workaround and it works for me. --- Arch Linux + GNOME 3.16.1
I also met this problem. fcitx can not work well in gnome 3.16.
Environment variables are not a supportable way to control session wide features like input methods (or anything else, really). GNOME is using ibus for input methods, and they can be centrally configured in the region and language settings panel. While you can probably rig things to make individual applications use another input method framework, that is not something we recommend.
Why not support other input method frameworks? You can not expect everyone to love ibus. Gnome should give users the freedom to try and use different input method frameworks. No matter which one is officially recommended, the others should be officially supported.
(In reply to Jiaping Bian from comment #5) > Why not support other input method frameworks? You can not expect everyone > to love ibus. We don't expect everyone to love ibus at all. We do expect that other input methods conform to a specific set of functionality, though. Not relying on environment variable when applications are moving to a model where they get activated via DBus or sandboxed (thus with a limited environment to begin with) is one of those requirements. > Gnome should give users the freedom to try and use different input method > frameworks. You can try and use them, but GNOME is not in the position of being able to support all of them. In this particular case, GNOME allows you to replace the GTK_IM_MODULE environment variable with the "overrides" GSettings key in the org.gnome.settings-daemon.plugins.xsettings schema, e.g.: gsettings set \ org.gnome.settings-daemon.plugins.xsettings overrides \ "{'Gtk/IMModule':'your-im-module'}" Which will be used even by DBus activated applications. > No matter which one is officially recommended, the others should > be officially supported. We cannot support more than on IM framework "officially", because we don't have infinite resources to spare to support the matrix of non-intersecting requirements and features. We chose to focus on IBus, even if it's not perfect, because it matches the requirements for how we want applications to be written or how they should behave.
(In reply to Emmanuele Bassi (:ebassi) from comment #6) > (In reply to Jiaping Bian from comment #5) > > Why not support other input method frameworks? You can not expect everyone > > to love ibus. > > We don't expect everyone to love ibus at all. We do expect that other input > methods conform to a specific set of functionality, though. Not relying on > environment variable when applications are moving to a model where they get > activated via DBus or sandboxed (thus with a limited environment to begin > with) is one of those requirements. > > > Gnome should give users the freedom to try and use different input method > > frameworks. > > You can try and use them, but GNOME is not in the position of being able to > support all of them. > > In this particular case, GNOME allows you to replace the GTK_IM_MODULE > environment variable with the "overrides" GSettings key in the > org.gnome.settings-daemon.plugins.xsettings schema, e.g.: > > gsettings set \ > org.gnome.settings-daemon.plugins.xsettings overrides \ > "{'Gtk/IMModule':'your-im-module'}" > That command works for me, but the value should be "{'Gtk/IMModule':<'your-im-module'>}". > Which will be used even by DBus activated applications. > > > No matter which one is officially recommended, the others should > > be officially supported. > > We cannot support more than on IM framework "officially", because we don't > have infinite resources to spare to support the matrix of non-intersecting > requirements and features. We chose to focus on IBus, even if it's not > perfect, because it matches the requirements for how we want applications to > be written or how they should behave. Thanks for your detail explanation. :) Now I know how it happened
(In reply to Emmanuele Bassi (:ebassi) from comment #6) Thanks for your response and thanks for the solution you provided. It does work.