Summary: | Add Fcitx support to Krita's AppImage | ||
---|---|---|---|
Product: | [Applications] krita | Reporter: | Tyson Tan <tysontanx> |
Component: | General | Assignee: | Halla Rempt <halla> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | halla, tamtamy.tymona, wengxt |
Priority: | NOR | ||
Version: | 4.3.0-beta2 | ||
Target Milestone: | --- | ||
Platform: | Other | ||
OS: | Linux | ||
Latest Commit: | https://invent.kde.org/graphics/krita/commit/c4d31b074964de0d4001d731545731cd46a3833d | Version Fixed In: |
Description
Tyson Tan
2020-06-04 21:19:32 UTC
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. |