Created attachment 1017099 [details] kde-first-and-second-login.png I installed Fedora 22 Beta (Fedora-Live-Workstation-x86_64-22_Beta-3.iso) in qemu using: nice ionice -c 3 qemu-kvm -machine pc-1.3 -enable-kvm -global qxl.ram_size=1x1024 -m 2048M -smp 2 -drive file=./Fedora-Live-Workstation-x86_64-22_Beta-3.iso.qcow2,index=0,media=disk,cache=unsafe -localtime -serial file:/tmp/qemu-Fedora-Live-Workstation-x86_64-22_Beta-3.iso.qcow2-output.log -name Fedora-Live-Workstation-x86_64-22_Beta-3.iso.qcow2 -cdrom /local/mfabian/iso/f22-Beta-RC3/Fedora-Live-Workstation-x86_64-22_Beta-3.iso -boot c -spice port=6000,disable-ticketing,streaming-video=off -vga qxl -display vnc=:4 -net nic -net user,hostname=Fedora-Live-Workstation-x86_64-22_Beta-3.iso.qcow2,hostfwd=tcp::5560-:22 -monitor stdio -usb The installation was done in Japanese and an “US English” keyboard was added in Anaconda in addition to the Japanese keyboard and the US keyboard moved to top priority. After the installation I added KDE sudo dnf groupinstall kde-desktop-environment Then I rebooted. After the reboot, I choose “plasma” (= KDE) in gdm and logged in. ibus-daemon was running, the environment variables were set correctly an the ibus-icon was visible in the KDE panel. Clicking on the ibus panel showed 日本語 - Kana Kanji <- Japanese input method 英語 - English (US) <- US English keyboard layout 日本語 - Japanese <- Japanese keyboard layout. “imsettings-info” tells me “Xinput file: /etc/X11/xinit/xinput.d/ibus.conf” And Japanese input works. Everything fine so far! But now I log out of KDE and log in again. Now there is a problem: - ibus-daemon is not running anymore - no ibus icon in the panel - “imsettings-info” tells me “Xinput file: /etc/X11/xinit/xinput.d/none.conf” - and of course Japanese input does not work now. See attached screenshots comparing the first and the second login to KDE. I did nothing else, only log out and log in again. Now I can start “ibus-setup”, it tells me that ibus-daemon is not running and asks me whether I want to start it. I say yes and see in the ibus-setup dialog that the same 3 input sources as above are configured. Now the ibus icon in the panel is back and Japanese input works again. But only until logging out and logging in again, then again ibus-daemon is not running. Now I can fix the problem permanently with imsettings-switch IBus After this, “imsettings-info” tells me “Xinput file: /etc/X11/xinit/xinput.d/ibus.conf” again. But that was already the case after the first login. Why was it changed to none.conf on the second login? And why is the change now permanent? Now I can log in and log out as often as I want and it keeps working.
Good question, I'm not sure how ibus is expected to setup/autostart in that case. Reassinging to ibus for feedback.
I cannot reproduce your problem. Did you install imsettings-qt ?
I did not install that: [mfabian@Fedora-Live-Workstation-x86_64-2 ~]$ rpm -q imsettings-qt パッケージ imsettings-qt はインストールされていません。 [mfabian@Fedora-Live-Workstation-x86_64-2 ~]$ Should sudo dnf groupinstall kde-desktop-environment have installed imsettings-qt?
My understanding is currently no way for KDE components to depend on i18n components. ibus-qt had to be installed by manual. If it's your problem, it's not an ibus issue.
(In reply to fujiwara from comment #4) > My understanding is currently no way for KDE components to depend on i18n > components. > ibus-qt had to be installed by manual. > If it's your problem, it's not an ibus issue. ibus-qt was installed, I did not have to install that manually: [mfabian@Fedora-Live-Workstation-x86_64-2 ~]$ rpm -q ibus-qt ibus-qt-1.3.3-5.fc22.x86_64 [mfabian@Fedora-Live-Workstation-x86_64-2 ~]$
And then probably comps could resolve imsettings-qt. If your problem is imsettings-qt installation, please move the right category.
(In reply to fujiwara from comment #6) > And then probably comps could resolve imsettings-qt. > If your problem is imsettings-qt installation, please move the right > category. I am not sure whether the missing imsettings-qt causes the problem. Even without imsettings-qt, Japanese input worked on the first login by default but not on the second login.
Does your problem resolve with imsettings-qt? ibus-daemon is kicked by imsettings. If ibus-daemon is not running, it's not an ibus issue.
(In reply to fujiwara from comment #8) > Does your problem resolve with imsettings-qt? It doesn’t seem to help.
(In reply to Mike FABIAN from comment #9) > (In reply to fujiwara from comment #8) > > Does your problem resolve with imsettings-qt? > > It doesn’t seem to help. I tried this: - install Fedora 22 Beta - log in to Gnome, open terminal, add KDE: “sudo dnf groupinstall kde-desktop-environment” - add imsettings-qt: “sudo dnf install imsettings-qt” - reboot - in gdm, select plasma - log in to KDE -> ibus works - log out - log in again -> ibus does not work Permanently fixable by executing: imsettings-switch IBus (Note: sometimes (but not always) the loudspeaker icon (the mixer) disappears as well on the second log in. I guess that has nothing to do with the ibus problem, but it is weird...)
I could reproduce your problem. From $HOME/.cache/imsettings/log 1. When the first login and imsettings cannot find $HOME/.config/Trolltech.conf but can run ibus-daemon. 2. When the second login and imsettings cannot find "[Qt]" in $HOME/.config/Trolltech.conf and seems to fail to save ibus in Trolltech.conf and failed to get ibus. 3. When the third login and imsettings cannot find "[Qt]" in $HOME/.config/Trolltech.conf but can save ibus in Trolltech.conf and can run ibus-daemon. This happens the second login only and probably I think the problem in imsettings-qt.
Is this still reproducible? can you attach $HOME/.cache/imsettings/log then?
I can still reproduce it on Fedora 22 final. For me it works only on the first login. Fujiwara San writes in comment#11 that it works for him on the third login. For me it does not work on the third login either.
Created attachment 1030530 [details] $HOME/.cache/imsettings/log $HOME/.cache/imsettings/log
I tested more carefully an actually the behaviour is a bit different now on Fedora 22 final: • first login: - ibus icon is in the panel - I open a konsole (Alt+F2 “konsole”) - I select kanji-kana in the panel - Japanese typing in konsole works - logout without closing konsole • second login: - ibus icon is in the panel. This is *different* to my previous test in comment#0 - one konsole opens automatically, remembered from previous session - I select kanji-kana in the panel - Japanese typing does *not* work in konsole, I get ASCII - I open a new konsole from the first one by typing konsole & on the command line - typing Japanese works in the new konsole • third login: - same behaviour as with second session, two konsole windows open automatically, remembered from previous session. Japanese input does not work in these automatically opened konsole windows. But when opening more konsole windows by typing konsole & Japanese input works in the new konsole windows.
Hmm, I don't see any fail from the log at least. can you compare the value in /proc/<pid>/environ between two konsole processes to see if it contains proper values for IM related thing?
[mfabian@Fedora-Live-Workstation-x86_64-2 ~]$ ps aux | grep konsole mfabian 9011 0.9 2.7 2883640 57180 ? Sl 15:20 0:02 /usr/bin/konsole -session 103022fa29a285000143272951300000007710011_1432732764_807398 mfabian 9556 2.1 2.8 2881412 57768 pts/1 Sl 15:22 0:01 konsole mfabian 9606 0.0 0.1 114352 2276 pts/2 S+ 15:24 0:00 grep --color=auto konsole [mfabian@Fedora-Live-Workstation-x86_64-2 ~]$ cat /proc/9011/environ | tr '\0' '\n' | grep ibus QT_IM_MODULE=ibus XMODIFIERS=@im=ibus GTK_IM_MODULE=ibus [mfabian@Fedora-Live-Workstation-x86_64-2 ~]$ cat /proc/9556/environ | tr '\0' '\n' | grep ibus QT_IM_MODULE=ibus XMODIFIERS=@im=ibus GTK_IM_MODULE=ibus [mfabian@Fedora-Live-Workstation-x86_64-2 ~]$ Process id 9011 is the first konsole, automatically started by the session manager. There Japanese input does not work. Process id 9556 is the second konsole started from the first one by “konsole &” where Japanese input works. The ibus related environment variables seem to be the same.
How about ibus then? At this moment, it is unlikely a bug in imsettings. the responsibility of imsettings is to bring the process up and set up the relevant environment variables to get IM working on desktops. We may need to investigate this from toolkits side and ibus.
will wait for result of /proc/<ibus pid>/environ to decide if I should assign this back to ibus once or not.
(In reply to Akira TAGOH from comment #19) > will wait for result of /proc/<ibus pid>/environ to decide if I should > assign this back to ibus once or not. Environment from which ibus process? ibus-daemon? These ibus related processes are running: [mfabian@Fedora-Live-Workstation-x86_64-2 ~]$ ps aux | grep mfabian.*ibus mfabian 2331 0.0 0.4 483896 8704 tty2 Sl 08:54 0:00 /usr/bin/ibus-daemon -r --xim mfabian 2340 0.0 0.3 407316 7732 tty2 Sl 08:54 0:00 /usr/libexec/ibus-dconf mfabian 2341 0.1 1.2 615376 26044 tty2 Sl 08:54 0:00 /usr/libexec/ibus-ui-gtk3 mfabian 2344 0.0 0.6 433792 13532 tty2 Sl 08:54 0:00 /usr/libexec/ibus-x11 --kill-daemon mfabian 2370 0.0 0.3 333508 7688 tty2 Sl 08:55 0:00 /usr/libexec/ibus-engine-simple mfabian 2522 0.1 2.5 541928 51308 tty2 Sl 08:55 0:00 /usr/libexec/ibus-engine-kkc --ibus mfabian 2800 0.0 0.1 117064 2304 pts/3 S+ 09:08 0:00 grep --color=auto mfabian.*ibus [mfabian@Fedora-Live-Workstation-x86_64-2 ~]$
Environment for the ibus-daemon process: [mfabian@Fedora-Live-Workstation-x86_64-2 ~]$ tr '\0' '\n' < /proc/2331/environ SHELL=/bin/bash DBUS_STARTER_ADDRESS=unix:abstract=/tmp/dbus-vsVFHhojNx,guid=7e3b8e07806db242b78dff4255a7551d DISPLAY=:0 XDG_CURRENT_DESKTOP=KDE XDG_RUNTIME_DIR=/run/user/1000 DESKTOP_SESSION=plasma PATH=/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin GDMSESSION=plasma USERNAME=mfabian XDG_VTNR=2 XDG_SESSION_TYPE=x11 XDG_SESSION_ID=1 DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-vsVFHhojNx,guid=7e3b8e07806db242b78dff4255a7551d XDG_SEAT=seat0 XAUTHORITY=/run/user/1000/gdm/Xauthority USER=mfabian DBUS_STARTER_BUS_TYPE=session GDM_LANG=ja_JP.UTF-8 LANG=ja_JP.UTF-8 XDG_SESSION_DESKTOP=plasma LOGNAME=mfabian HOME=/home/mfabian LC_CTYPE=ja_JP.UTF-8 GTK_IM_MODULE=ibus QT_IM_MODULE=ibus XMODIFIERS=@im=ibus [mfabian@Fedora-Live-Workstation-x86_64-2 ~]$ tr '\0' '\n' < /proc/2331/environ | grep ibus GTK_IM_MODULE=ibus QT_IM_MODULE=ibus XMODIFIERS=@im=ibus [mfabian@Fedora-Live-Workstation-x86_64-2 ~]$
Thanks. so imsettings did the job as expected AFAICS. I guess we need to investigate this from ibus side again. assigning this back.
It seems I cannot reproduce the original issue. (In reply to Mike FABIAN from comment #15) > - one konsole opens automatically, remembered from previous session This had never been mentioned. Probably he found another problem. This problem happens because konsole runs before ibus-daemon connects to the bus. I can reproduce this problem but I'd like to see see another bug.
Would you test the following plugin which is put in /usr/lib64/qt5/plugins/platforminputcontexts/ ? https://fujiwara.fedorapeople.org/ibus/20150730/libibusplatforminputcontextplugin.so
I did put the plugin from comment#24 into /usr/lib64/qt5/plugins/platforminputcontexts/ and this makes the konsole which is remembered from the previous session and opened automatically work with ibus. So this updated plugin seems to solve the problem. Thank you!
fujiwara, if you'd like to take the approach of replacing the plugin from qt5-qtbase with this one (from ibus-qt?), I could help make that happen. (I was guessing that may a goal, based on comments here and on upstream qt mailing lists)
(In reply to Mike FABIAN from comment #25) > I did put the plugin from comment#24 into > /usr/lib64/qt5/plugins/platforminputcontexts/ and this makes the konsole > which > is remembered from the previous session and opened automatically > work with ibus. > > So this updated plugin seems to solve the problem. Thank you! Thank you for your test.
(In reply to Rex Dieter from comment #26) > fujiwara, if you'd like to take the approach of replacing the plugin from > qt5-qtbase with this one (from ibus-qt?), I could help make that happen. > > (I was guessing that may a goal, based on comments here and on upstream qt > mailing lists) Thank you for your suggestion. It seems the main issue is that Qt has LGPL and the commercial license and if the customers select the commercial license, the plugin also has to be the commercial license. Probably I'm happy to port the plugin from qt5-qtbase to ibus-qt but I don't wish to maintain the internal patches in Fedora. So I will try to fix qtbase upstream for this bug at the moment.
https://bugreports.qt.io/browse/QTBUG-47657
I've been working on qt5 korean issues in qtbase 5.6 and probably I will integrate this feature in 5.7 while the patch review is done. Therefore I will ask to back port the feature in Fedora 24.
Integrated the patch in qtbase 5.6. http://code.qt.io/cgit/qt/qtbase.git/commit/?id=4954ad6dbc9c37ac4f8b9cae8808c31f1d55c698
This bug appears to have been reported against 'rawhide' during the Fedora 24 development cycle. Changing version to '24'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora24#Rawhide_Rebase
This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune with any questions
I confirmed qt5-qtbase-gui-5.6.0-0.37.rc.fc24 includes this fix at least.