Fcitx is an Input Method tool to allow a user to input non-English letters. It's the only one of its kind that currently works under KDE Plasma, and it's also the most widely used one. IBUS is also an Input Method, but it primarily works under GNOME. Krita's AppImage supports IBUS but not Fcitx. As a result, KDE Plasma users cannot input non-English letters in the AppImage version of Krita. ### From this bug report: https://github.com/qTox/qTox/pull/5825 Qt needs some libraries to be present in order to support IBus, Fcitx and Uim IMEs. Specifically: plugins/platforminputcontexts/libibusplatforminputcontextplugin.so plugins/platforminputcontexts/libfcitxplatforminputcontextplugin.so plugins/platforminputcontexts/libuimplatforminputcontextplugin.so libQt5Gui in Debian already comes with the IBus plugin, so IBus input should have worked all this time, but not Fcitx and Uim, for those you need to manually install fcitx-frontend-qt5 and uim-qt5 (renamed to uim-qt5-immodule in Buster) packages. To include the plugin libraries into qTox AppImage we have to simply install those packages, linuxdeployqt or whatever includes them since these are Qt plugins. ### Note that Krita installed from the official repository of a distro is not affected, because those libraries are installed along with KDE Plasma and Fcitx. ### The related package is called: fcitx-qt5 (current version) fcitx5-qt (future version) in Manjaro. Their project is: https://github.com/fcitx/fcitx-qt5 ### This issue exists in every major KDE AppImages (and other Qt-based AppImages): * Krita * Kdenlive * Digikam If we solve this problem and share the knowledge, it'll enable non-English speaker to use our AppImages without the Input Method barrier. Thanks!
We won't be able to do this before the 4.3.0 release; since these are Qt plugins, we cannot just use the distribution's build, but will have to build them ourselves. Assuming https://github.com/fcitx/fcitx5.git and fcitx-qt5 are the right repoes to build, we will need the following extra deps: intltool libevdev-dev libgettextpo0 libinput-dev libmtdev-dev librhash0 libudev-dev libwacom-dev
No need hurry. Please take your time. There are not that many users actually affected by this issue. ^^; Thank you Boud, and please let me know when my help is needed.
This seems like something we should add to Krita 5 todo list, possibly?
Actually, #1 is not pointing to the exact right repo. To support fcitx(both 4 and 5), either https://github.com/fcitx/fcitx-qt5 or https://github.com/fcitx/fcitx5-qt can be used. And you do not need https://github.com/fcitx/fcitx{,5} to build it. There is an cmake option that only build the plugin part without the library. https://github.com/fcitx/fcitx-qt5/blob/77cb995a1ed0c30401e43388842b99610b53569e/CMakeLists.txt#L12 I don't think it will pull in any additional dependency that is not in Qt's dependency (the only explicit ones are xkbcommon, which is also used by Qt)
Ah, thanks for the info! I'll take a look at it again. (Unless you want to work on a patch?)
Git commit 5264f41ee36cbb98743e8f851ff6cb95cde4bd38 by Halla Rempt. Committed on 15/04/2021 at 13:03. Pushed by rempt into branch 'master'. Add fcitx-qt to the deps M +1 -0 3rdparty/CMakeLists.txt A +14 -0 3rdparty/ext_fcitx-qt/CMakeLists.txt https://invent.kde.org/graphics/krita/commit/5264f41ee36cbb98743e8f851ff6cb95cde4bd38
Git commit c4d31b074964de0d4001d731545731cd46a3833d by Halla Rempt. Committed on 15/04/2021 at 13:06. Pushed by rempt into branch 'master'. Build the fcitx-qt5 plugin M +1 -1 build-tools/windows/build.cmd M +1 -0 packaging/android/androidbuild.sh M +1 -0 packaging/linux/appimage/build-deps.sh M +1 -0 packaging/macos/osxbuild.sh https://invent.kde.org/graphics/krita/commit/c4d31b074964de0d4001d731545731cd46a3833d
Let's see whether it works in the next nightly builds -- I'll kick off deps builds now.
Question: is this only useful on Linux, or should the plugin be enabled on other platforms as well?
Thank you Halla. Fcitx is Linux specific. We can already use IME in Krita under Windows without issue (though Krita 4 doesn't accept non-latin1 letters for resources).
Okay, then I won't build it for other platforms
Git commit 27dc312cc18ae542c054ffbbbb631dcee024b3c4 by Halla Rempt. Committed on 15/04/2021 at 13:37. Pushed by rempt into branch 'master'. Make fcitx-qt depend on Qt M +1 -0 3rdparty/ext_fcitx-qt/CMakeLists.txt https://invent.kde.org/graphics/krita/commit/27dc312cc18ae542c054ffbbbb631dcee024b3c4
I tested krita-5.0.0-prealpha-db8a16f-x86_64.appimage under Archlinux with fcitx5, I was unable to use fcitx5 in that appimage. We often can't choose which version of fcitx under Linux, it's either fcitx(4) OR fcitx5 for a certain distro. I wonder if we need to package both fcitx-qt5 and fcitx5-qt at the same time?
I tried krita-5.0.0-prealpha-db8a16f-x86_64.appimage with fcitx(4), it didn't work either.
I don't know...
If there is any more important tasks at hand, I say just leave this for the future. I will ask around in KDE China group. Someone there knows the maintainer of fcitx and some Qt engineers. Maybe they know a thing or two.
Cavendish from Qt said we might need this plugin: https://github.com/fcitx/fcitx-qt5/tree/master/platforminputcontext I don't know about the details though. It's beyond my ability at this point :P
(In reply to Tyson Tan from comment #13) > I tested krita-5.0.0-prealpha-db8a16f-x86_64.appimage under Archlinux with > fcitx5, I was unable to use fcitx5 in that appimage. We often can't choose > which version of fcitx under Linux, it's either fcitx(4) OR fcitx5 for a > certain distro. I wonder if we need to package both fcitx-qt5 and fcitx5-qt > at the same time? No, for compatibility, both im module support fcitx4 / 5. Actually I just tested with https://binary-factory.kde.org/job/Krita_Nightly_Appimage_Build/lastSuccessfulBuild/artifact/krita-5.0.0-prealpha-b55fcd5-x86_64.appimage Both fcitx4/5 works fine with this image on my system. Did you set QT_IM_MODULE=fcitx ? run it with QT_DEBUG_PLUGINS=1 should gives you QFactoryLoader::QFactoryLoader() looking at "/tmp/.mount_krita-43CzQH/usr/plugins/platforminputcontexts/libfcitxplatforminputcontextplugin.so" Found metadata in lib /tmp/.mount_krita-43CzQH/usr/plugins/platforminputcontexts/libfcitxplatforminputcontextplugin.so, metadata= { "IID": "org.qt-project.Qt.QPlatformInputContextFactoryInterface.5.1", "MetaData": { "Keys": [ "fcitx" ] }, "archreq": 0, "className": "QFcitxPlatformInputContextPlugin", "debug": false, "version": 330752 } Got keys from plugin meta data ("fcitx"
IMHO at this point since it at least works for me, it's likely to be a configuration issue (input method may require set some env var so it can goes wrong) instead of packaging issue. So I'd suggest close as fixed. For Tyson's issue feel free to ping me on KDE China and I can help you to take a look.
Just tried to check krita-5.0.0-prealpha-db8a16f-x86_64.appimage, it is simply not include the required file. and newer one works ./krita-5.0.0-prealpha-b55fcd5-x86_64.appimage. Probably due to how the krita jenkins job works, krita-5.0.0-prealpha-db8a16f-x86_64.appimage might not pick up the latest artifact of Krita_Nightly_Appimage_Dependency_Build so it doesn't include fcitx plugin. Tyson@, Please just try a newer image and it should just works.
Thanks! I can confirm it works on the lastest Nightly appimage as well. I will let the developers of digikam and kdenlive know about this too.