Some months ago I posted on Fedora’s forum asking for help in how to get Fedora KDE with Japanese input working together with the on-screen keyboard. The reason for this is that I’m running a Lenovo Yoga 7 folding laptop, which, when in tablet mode, needs the OSK to be able to input text normally, (ie. using a “normal” keyboard layout). Setting the virtual keyboard to fcitx5 seems to be the general approach to handle japanese input, as that translates the keyboard inputs to japanese on the fly, but unfortunately this kills the OSK.
I don’t really understand why these features are incompatible as they appear to be unrelated. I did wait until Fedora 43 to see if the issue was fixed and/or if someone would provide an answer to my original post, but I still have no answer
A user on the Fedora forum suggested I ask here So, is there something I’m missing here? Is there a way to enable the OSK in tablet mode while having japanese input work when in normal mode?
I’m having the same issue. Plasma keyboard stops working at all if I setup fcitx5 for Japanese typing, making tablet mode near unusable. Haven’t gotten any responses yet.
So from what I can tell, this is a case of an unfortunate software abstraction.
fcitx5 is an input method framework whereas Maliit and Plasma Keyboard are merely “input surfaces”. Treating them both under the same “virtual keyboard” umbrella really makes no sense because they serve completely different purposes and thus should not be mutually exclusive.
For this to work correctly, OSKs and input method frameworks should be treated as separate entities, where an OSK would just feed input to the input method framework.
I understand this is a relatively niche usecase, but this seems to be more of a design issue than a true technical limitation. It would be great if these components could be decoupled in the future!
For now I guess we are out of luck… unless there’s some way to automatically switch between virtual keyboards when “tablet mode” is detected?
That’s really unfortunate and this really shouldn’t be considered as a niche issue for those who care about worldwide adoption of linux (or just KDE, it seems GNOME doesn’t have this issue?). This is one of the more surprising limitations I’ve encountered, feels like an oversight by predominantly latin-alphabet-only developers. I’m hoping the OSK is the more niche part, which is understandable, but touchscreen devices are already very common and are only becoming more common on “desktop” (+ laptop and 2-in-1) computers.
I guess people might consider fcitx5 (or IBus or other IMEs, which I assume work similarly) to be the more “hacky” part of the equation rather than Plasma Keyboard (or maliit or other OSKs). But none of them can be blamed if the only way either of them can be implemented is as a virtual keyboard, with only one able to be set at a time. As you said, IMEs and OSKs should be considered separate components and should not have to fight for the one slot they can fit in.
I too hope they be decoupled or the issue can be resolved in some other way soon. A separate setting for tablet mode is a good proposal.
(Though I haven’t been able to get plasma keyboard to show up at all ever since I installed fcitx, even when I set it back as the virtual keyboard and revert all other keyboard related settings, short of completely uninstalling fcitx5 which I don’t want to do. Seems like fcitx5 is autostarting or some-other-how overriding whatever my settings are, as the IME still runs when I set plasma keyboard as the virtual keyboard and plasma keyboard never shows up even if I tap on the system tray icon)
It is a real technical limitation, at least for now. Currently only standard way of providing input as a Virtual Keyboard or an IME ( like FCITX or IBUS ) is through the same Input Method protocol. So only one of them can be active at the same time. ( GNOME uses a non-standard way of doing things where the Virtual Keyboard acts as an intermediate layer between physical input and the Input method. This basically requires the Keyboard to be backed into the Shell )
There were some discussions by KDE devs on how to fix this without breaking standards or waiting for Wayland protocol changes earlier. I can’t find any follow up on it though.
About settings, KDE Devs decided to name the settings page for Input Method “Virtual Keyboard” settings since that’s more understandable for users. But it does create confusion when fcitx is involved since it is not a virtual keyboard.
So, is there something I’m missing here? Is there a way to enable the OSK in tablet mode while having japanese input work when in normal mode?