GNOME's virtual keyboard allows to show the virtual keyboard by swiping from the bottom edge upwards while keeping focus in the current window, and swiping from the top of the virtual keyboard downwards hides the keyboard. The first works around misbehaving apps who do not cooperate with virtual keyboards and never show them even if running natively on wayland (like Chrome/ium). With Maliit only the second action is possible. My first instinct is that this could be implemented as another action in the Touchscreen KCM. This also seems like consistent behavior in case the user wants to hide the keyboard to see the whole screen before getting back to writing, but perhaps this is best implemented in maliit itself.
Yes, I think your idea makes sense!
This is not all that simple, we'd need first to have a mode for kwin to communicate with clients and send them keyboard events rather than text input which is what we generally do. This is a general requirement for XWayland applications I guess, so it probably should be done eventually. Either way, I'd say insisting on these "applications that don't behave" to behave is the only way to have a good experience overall in the long term. In the meantime, sure, we can add workarounds like that. It's not trivial though and it will require a considerable amount of effort. Moving the bug to KWin as it's not a settings issue.
For what it's worth, the keyboard appeared correctly with all of the apps I regularly use while testing tonight. So if you think it's too much effort for a hypothetical problem, I understand.
Well, it wouldn't be for a hypothetical situation. There's the case where the application doesn't implement the text-input protocol (e.g. any XWayland app). Then we need to trick the virtual keyboard into emulating a physical keyboard and such an action would be necessary. I'll rename this issue to re-frame this bug report.
(In reply to Thiago Sueto from comment #0) > GNOME's virtual keyboard allows to show the virtual keyboard by swiping from > the bottom edge upwards while keeping focus in the current window, and > swiping from the top of the virtual keyboard downwards hides the keyboard. > > The first works around misbehaving apps who do not cooperate with virtual > keyboards and never show them even if running natively on wayland (like > Chrome/ium). > > With Maliit only the second action is possible. > > My first instinct is that this could be implemented as another action in the > Touchscreen KCM. This also seems like consistent behavior in case the user > wants to hide the keyboard to see the whole screen before getting back to > writing, but perhaps this is best implemented in maliit itself. Thiago, you are on a roll! This is the thing I've quoted you on today. This is the only major issue that I have with Plasma Wayland right now on my Surface Pro 4 tablet. There are several applications that I need/want to use that Maliit won't work with, forcing me to connect an external keyboard, or log into GNOME Wayland. Those applications include, but are not limited, Spotify, OpenRocket, MATLAB, Chrome Web Browser, Discord, Bluejeans, and Steam, to name a few. Firefox is really the only non-Qt/Plasma application that I use that works with the virtual keyboard, which is a real letdown. I like Maliit, but compared to the Qt Virtual Keyboard, Onboard (on Xorg), and GNOME's virtual keyboard it's too limited. I don't know what trickery the GNOME folks are using, but EVERY application works with their virtual keyboard in Wayland. Maybe your input folks might want to talk to their input folks?
Squeekboard is a virtual keyboard that works with Gnome. Here are the protocols it uses: https://gitlab.gnome.org/World/Phosh/squeekboard/-/tree/master/protocols. It sounds like kwin would need to implement virtual_keyboard_unstable_v1 (and route the keystrokes approriately) in order for a virtual keyboard to work everywhere.
(In reply to kelnio@yahoo.com from comment #5) > (In reply to Thiago Sueto from comment #0) > > GNOME's virtual keyboard allows to show the virtual keyboard by swiping from > > the bottom edge upwards while keeping focus in the current window, and > > swiping from the top of the virtual keyboard downwards hides the keyboard. > > > > The first works around misbehaving apps who do not cooperate with virtual > > keyboards and never show them even if running natively on wayland (like > > Chrome/ium). > > > > With Maliit only the second action is possible. > > > > My first instinct is that this could be implemented as another action in the > > Touchscreen KCM. This also seems like consistent behavior in case the user > > wants to hide the keyboard to see the whole screen before getting back to > > writing, but perhaps this is best implemented in maliit itself. > > Thiago, you are on a roll! This is the thing I've quoted you on today. > > This is the only major issue that I have with Plasma Wayland right now on my > Surface Pro 4 tablet. There are several applications that I need/want to use > that Maliit won't work with, forcing me to connect an external keyboard, or > log into GNOME Wayland. Those applications include, but are not limited, > Spotify, OpenRocket, MATLAB, Chrome Web Browser, Discord, Bluejeans, and > Steam, to name a few. Firefox is really the only non-Qt/Plasma application > that I use that works with the virtual keyboard, which is a real letdown. I > like Maliit, but compared to the Qt Virtual Keyboard, Onboard (on Xorg), and > GNOME's virtual keyboard it's too limited. I don't know what trickery the > GNOME folks are using, but EVERY application works with their virtual > keyboard in Wayland. Maybe your input folks might want to talk to their > input folks? There is another point to consider, most applications rely on keyboard shortcuts, and Maliit does not provide them, and hence it is basically useless: you have a keyboard, that does output text, but that can't really interact with your application. So you have to plug an external keyboard and Maliit becomes useless. For example, Okular requires Ctrl+Shift+F to leave full screen mode, or alternatively an external mouse with a proper right click, but if you have one you probably have an external keyboard too. For the time being I had to switch to Gnome with this keyboard: https://extensions.gnome.org/extension/4413/improved-osk/ I also had opportunities for glimpses at Squeekboard when I tried Phosh, and the layout seemed nice. Maliit only allows for text, it does not allow to operate the applications: what good is text if you can't use the applications it's meant for. For the present Maliit is the only offer for kde users, and it's hindering the whole experience. We could wish applications would work with only a touch screen and a keyboard allowing for text only and emoji, but it is not the case.
In progress with https://invent.kde.org/plasma/kwin/-/merge_requests/2426
Git commit 345736735e6668ff5dd91f2e40bfad70482ffe2d by Arjen Hiemstra. Committed on 01/09/2022 at 14:41. Pushed by ahiemstra into branch 'master'. Add a fallback path for input when there is no text-input An application that does not support text-input has no way of communicating with the input method, so even if you show the input method the application receives nothing. As a fallback, instead send fake key events so the application still gets something at least. The key events are synthesised based on the text string that the input method sends, which may result in things that do not actually correspond to real keys. Unfortunately I do not see a way around that. M +74 -0 autotests/integration/inputmethod_test.cpp M +68 -14 src/inputmethod.cpp https://invent.kde.org/plasma/kwin/commit/345736735e6668ff5dd91f2e40bfad70482ffe2d
Git commit e2889c86fc88ea2d62faaf077770348f70a47c13 by Aleix Pol Gonzalez. Committed on 09/09/2022 at 01:13. Pushed by apol into branch 'master'. inputmethod: Allow forcing the display of the input method Adds support to the new information offered by KWin. Now it can tell us that the current client doesn't support Wayland input methods. Therefore, it sets the plasmoid in a new "unsupported" state that will offer to force an activation when triggered. KWin will then be able to emulate a keyboard and it all should work to some extent. Depends on https://invent.kde.org/plasma/kwin/-/merge_requests/2907 M +25 -7 applets/manage-inputmethod/contents/ui/manage-inputmethod.qml M +1 -0 components/keyboardlayout/virtualkeyboard.h https://invent.kde.org/plasma/plasma-workspace/commit/e2889c86fc88ea2d62faaf077770348f70a47c13
*** Bug 390705 has been marked as a duplicate of this bug. ***