Description of problem: ----------------------- Since I upgraded to fedora 25, I cannot type in japanese using ibus and mozc in qt application such as, for example, scribus, krita or the Qt frontend to cmake. Instead when selecting the "hiragana" submode, latin character are type as if in "direct input" submode. I quickly tried to input japanese text with ibus-anthy with no more success. Both mozc and anthy works fine with GTK2/GTK3 applications I noticed this while trying to describe the issue in Bug#1395381. Version-Release number of selected component: --------------------------------------------- # dnf list ibus-\* Last metadata expiration check: 0:23:47 ago on Wed Dec 7 23:57:23 2016. Installed Packages ibus-anthy.x86_64 1.5.9-1.fc25 @fedora ibus-anthy-python.noarch 1.5.9-1.fc25 @fedora ibus-chewing.x86_64 1.5.1-1.fc25 @fedora ibus-gtk2.x86_64 1.5.14-3.fc25 @fedora ibus-gtk3.x86_64 1.5.14-3.fc25 @fedora ibus-handwrite.x86_64 3.0.0-4.fc24 @@commandline ibus-hangul.x86_64 1.5.0-6.fc24 @@commandline ibus-kkc.x86_64 1.5.22-4.fc24 @@commandline ibus-libpinyin.x86_64 1.8.0-2.fc25 @updates ibus-libs.x86_64 1.5.14-3.fc25 @fedora ibus-m17n.x86_64 1.3.4-20.fc24 @@commandline ibus-mozc.x86_64 2.17.2322.102-1.fc25 @fedora ibus-qt.x86_64 1.3.3-11.fc25 @fedora ibus-rawcode.x86_64 1.3.2-7.fc24 @@commandline ibus-setup.noarch 1.5.14-3.fc25 @fedora ibus-typing-booster.noarch 1.5.13-1.fc25 @updates ibus-wayland.x86_64 1.5.14-3.fc25 @fedora # dnf list anthy mozc Installed Packages anthy.x86_64 9100h-29.fc24 @@commandline mozc.x86_64 2.17.2322.102-1.fc25 @fedora How reproducible: ----------------- Always Steps to Reproduce: ------------------- 0.Make sure to have ibus-qt and ibus-mozc installed 1.Go to the general gnome settings panel, "Regions and languages" menu. 2.Add an input in Japanese (Mozc) 3.Find the ibus on the top right of gnome 3 and switch the IME to Japanese. 4.In the same pop-up to select mozc as the IME, make sure your input mode is set to "hiragana". 4.Open gedit. Type some japanese gibberish. It's in hiragana. 5.Open a qt application such as cmake-gui. Try to input japanese gibberish in any text entry. It's latin character as if you're still using qwerty or whatever latin keyboard layout. Additional info: ---------------- My default layout is dvorak. I set Mozc to form kana by using that dvorak layout, not to input kana directly. However setting Mozc to a kana keymap does not solve the problem at all : I still type latin characters with a dvorak keymap.
Please run ``ibus restart`` for the workaround. > I set Mozc to form kana by using that dvorak layout, It's a ibus-mozc issue not to provide the customization but not ibus core. You can modify layout tag in /usr/share/ibus/component/mozc.xml
Created attachment 1229436 [details] My /usr/share/ibus/component/mozc.xml
For some obscure reason, you cannot select "ibus-mozc" as the bug's components. I selected "ibus-qt" instead, now selecting "mozc". I'm far from having a good understanding of ibus and I don't know what a change in "layout tag" would do. I have the same issue wih both mozc and anthy yet their xml files in /usr/share/ibus/component are quite different. What do you suggest I do with them ? I've attached my /usr/share/ibus/component/mozc.xml file.
This looks like the application problem. I tried scribus, adding a text frame into the doc and type something on the story editor. the input event is surely sending to mozc because I can see the input sugggestion window there. but can't commit the strings. One more thing I think it is the application problem is that IM works on the input box on the file dialog say. please check.
My issue is slightly different. I cannot see any suggestion pop-up window, I only type with the latin layout. By "application" do you mean the whole Qt library ? Because I have the issue with all Qt applications, be it Qt4 (scribus, tagainijisho) or Qt5 (vlc, krita). But I do *not* have the problem with GTK applications such as nautilus, gimp or firefox. Some Qt Applications, such as VLC, uses the native gnome/GTK file dialog, so it works there, but it doesn't work in "true" qt text entries, such as the ones you can find in many preference options.
(In reply to N.Brack from comment #3) > What do you suggest I do with them ? I've attached my > /usr/share/ibus/component/mozc.xml file. You can modify "default" to "jp" in the layout tag. (In reply to N.Brack from comment #3) > For some obscure reason, you cannot select "ibus-mozc" as the bug's > components. I selected "ibus-qt" instead, now selecting "mozc". I mean the layout issue only for mozc. /usr/libexec/ibus-setup-anthy has the customization for the layout. But ibus is still a valid bug category rather than mozc for your input issue. I hope you confirmed ``ibus restart`` is a workaround.
sounds like we are talking about multiple issues here which can't be addressed in one. I see IM doesn't work on some applications (at least scribus) but works on the basic featured widgets (e.g. file dialog) on Qt. that would means ibus works on Qt itself properly. plus, the input through ibus on the story editor in scribus doesn't even work with ibus-kkc. thus, I'd say that is the scribus issue. for the layout, mozc has the properties UI though, "mozc doesn't have a customization for layout" isn't true. "it isn't supported so far" is true.
(In reply to Akira TAGOH from comment #7) > for the layout, mozc has the properties UI though, "mozc doesn't have a > customization for layout" isn't true. "it isn't supported so far" is true. Seems an unclear comment. Whether mozc supports the customization or not, "mozc doesn't have a customization for layout" is true and I don't pay attention to the mozc behavior. sysadmin can change the layout by manual.
I meant it is NOTABUG.
> I hope you confirmed ``ibus restart`` is a workaround. I changed the value in mozc.xml, and rebooted my computer, that didn't do the trick. Typing ``ibus restart`` as user does absolutely nothing and as root gives: # ibus restart Can't connect to IBus. > I see IM doesn't work on some applications (at least scribus) but works on the basic featured widgets (e.g. file dialog) on Qt. Unless I understand what you mean by "file dialog", that's not the case for me. Inputting japanese in the Qt "open file" dialog for scribus doesn't work for me, neither does krita's or tagainijisho's. VLC uses a GTK file dialog (I can really easily spot this as my qt theme is light and my GTK theme is dark), so it works. So in _my_ case I may still have an issue between Qt and ibus. > thus, I'd say that is the scribus issue. It's not scribus-only issue. It's at least a krita + tagainisho + cmake-gui + VLC + QtCreator + QtDesigner + scribus issue. The more I test, the more it confirms Qt is affected, GTK isn't.
(In reply to N.Brack from comment #10) > > I hope you confirmed ``ibus restart`` is a workaround. > I changed the value in mozc.xml, and rebooted my computer, that didn't do > the trick. Typing ``ibus restart`` as user does absolutely nothing and as > root gives: > > # ibus restart > Can't connect to IBus. > You should run the ibus command with the current user account which runs ibus-daemon but should not run it with root account. I mean your issue might be the timing issue between the KDE session and ibus-daemon and I'd ask ``ibus restart`` after you log into the KDE session. Modifying mozc.xml is to fix kana layout but not the input activation.
> You should run the ibus command with the current user account which runs ibus-daemon but should not run it with root account. I wasn't clear enough. I tried both, but using as user space, seems to do nothing to fix the (input activation) issue, and doesn't tell me anything. Oh, and I use gnome 3, not KDE... > Modifying mozc.xml is to fix kana layout but not the input activation. Ah... all right. But it didn't work. Instead of whatever latin layout I was using, it uses the japanese latin layout. Anyway I was more concerned about the input activation.
(In reply to N.Brack from comment #12) > > You should run the ibus command with the current user account which runs ibus-daemon but should not run it with root account. > > I wasn't clear enough. I tried both, but using as user space, seems to do > nothing to fix the (input activation) issue, and doesn't tell me anything. > > Oh, and I use gnome 3, not KDE... Sorry, I missed you don't use KDE and I don't reproduce your problem. Did you see your problem with kwrite? Did you export QT_IM_MODULE variable? How is the result to run ``strace kwrite |& grep platforminput`` ? > > Modifying mozc.xml is to fix kana layout but not the input activation. > > Ah... all right. But it didn't work. Instead of whatever latin layout I > was using, it uses the japanese latin layout. > > Anyway I was more concerned about the input activation. I mean to stick 'jp' layout for ibus-mozc with modifying mozc.xml. If you wish to assign kana keys on us-dvorak keymaps, kana key customization would be needed. ibus-anthy settings dialog has the customization but I don't see it on mozc one.
Ping N.Brack . Can you reply my questions in comment #13?
Created attachment 1234087 [details] Output of `strace kwrite |& grep platforminput` > Did you see your problem with kwrite? Yes. I have the problem with kwrite > Did you export QT_IM_MODULE variable? I noticed QT_IM_MODULE was already set to "xim". I've set it up to "ibus". It still failed. But I then noticed XMODIFIERS was set to "@im=none". I've set it up to "@im=ibus". And now qt programs launched with those variable exported work ! I don't know which config file do export those variable with erroneous values. > How is the result to run ``strace kwrite |& grep platforminput`` ? Attached as a file.
(In reply to N.Brack from comment #15) > Created attachment 1234087 [details] > Output of `strace kwrite |& grep platforminput` Your attachment seems to use xim but not ibus. > > Did you export QT_IM_MODULE variable? > I noticed QT_IM_MODULE was already set to "xim". I've set it up to "ibus". > It still failed. But I then noticed XMODIFIERS was set to "@im=none". I've > set it up to "@im=ibus". And now qt programs launched with those variable > exported work ! This would be a reason and you still does not set QT_IM_MODULE correctly. Using XMODIFIERS for Qt has several problems in your case because qt module is xim. You will know `env QT_IM_MODULE=ibus kwrite` works fine. Probably your setting QT_IM_MODULE is not correct.
> You will know `env QT_IM_MODULE=ibus kwrite` works fine. Actually, yes, it works for kwrite. Yesterday I exported QT_IM_MODULE correctly and tried scribus with that exported variable, not kwrite, and it didn't work. Scribus still doesn't work today with QT_IM_MODULE set up correctly. But kwrite do. > Probably your setting QT_IM_MODULE is not correct. Yeah and I'm confused why. Grepping for QT_IM_MODULE in /etc/, I find the variable is set up in /etc/X11/xinit/xinput.d/ibus.conf with the following snippet of code: if test -f /usr/lib64/qt5/plugins/platforminputcontexts/libibusplatforminputcontextplugin.so || \ test -f /usr/lib/qt5/plugins/platforminputcontexts/libibusplatforminputcontextplugin.so || \ test -f /usr/lib64/qt4/plugins/inputmethods/libqtim-ibus.so || \ test -f /usr/lib/qt4/plugins/inputmethods/libqtim-ibus.so; then QT_IM_MODULE=ibus else QT_IM_MODULE=xim fi But /usr/lib64/qt5/plugins/platforminputcontexts/libibusplatforminputcontextplugin.so do exists as a regular file (along a file named libcomposeplatforminputcontextplugin.so), so that environment variable should be set to "ibus". Also all files in /etc/X11/xinit/xinput.d export GTK_IM_MODULE as well, yet that variable cannot be found with `printenv | grep IM_MODULE`.
/etc/X11/xinit/xinput.d/ibus.conf won't be used on GNOME. gnome-settings-daemon do the job.
Transferring to scribus. Qt4 application works fine with input methods while ibus-qt needs to be rebuilt.
Rebuild is done: https://koji.fedoraproject.org/koji/taskinfo?taskID=17022417
By the way, exporting `QT_IM_MODULE=ibus` fixes Qt5 apps, but it doesn't work with either Scribus, Tagainijisho, krename or any Qt4 application I could try. All those Qt4 applications work by exporting `XMODIFIERS=@im=ibus`.
(In reply to N.Brack from comment #21) > By the way, exporting `QT_IM_MODULE=ibus` fixes Qt5 apps, but it doesn't > work with either Scribus, Tagainijisho, krename or any Qt4 application I > could try. All those Qt4 applications work by exporting > `XMODIFIERS=@im=ibus`. I confirmed the open dialog in krename works fine with ibus-qt. Did you install ibus-qt-1.3.3-12 above?
This message is a reminder that Fedora 25 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 25. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '25'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 25 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 25 changed to end-of-life (EOL) status on 2017-12-12. Fedora 25 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.