According to https://github.com/Hoverth/wayland-virtual-keyboards/blob/main/README.md#desktop-keyboards, desktop On-Screen Keyboards (OSK) is piece of software that shows a keyboard layout, complete with special keys, modifier keys and levels. Relevant example of this kind of software is Onboard, that currently works only on X11 because of some limitations of Wayland for normal clients. There is a workaround to make it work on Wayland and in particular under the KWin session by launch it with GDK_BACKEND=x11 as XWayland app with some application settings tweak. The main issue with providing native solution under Wayland is lack of features like _NET_WM_STATE_ABOVE, _NET_WM_STATE_STAYS_ON_TOP properties to stay above other clients and InputHint WM_HINT (false) to discard input focus. On the one hand, this is a manifestation of Wayland's safety-focused design, but from the other side there are protocols like wlr_layer_shell that provide the ability for unprivileged clients to do something similar by set layer::top and keyboard_interactivity::none, which fully reproduces the Onboard behavior in sense of z-position and input focus, but with loose of client decorations, positioning and resize. Is it possible in the future to implement similar functionality natively, without involving XWayland, or will this become the same security weakness as in the case of using it?
>On the one hand, this is a manifestation of Wayland's safety-focused design Please don't repeat that invalid social media drivel here. >Is it possible in the future to implement similar functionality natively, Yes. There are numerous wayland OSKs. Maliit and the upcoming plasma-keyboard. Neither are not movable, but that's fixable.
> Please don't repeat that invalid social media drivel here. I may be wrong, but as far as I know, some basic functions of the most common desktop windowing systems (some of which were listed above) that are not present in the xdg_* or even ext_* protocol namespaces are not adopted, primarily not due to lack of demand, but for reasons related to possible unfair use by clients. Apologize if I'm wrong. > Neither are not movable, but that's fixable. Is it fixable providing new Plasma-specific Wayland protocol for this or somehow else like in situation with xx-pip (in prospect)? I understand that on-screen keyboard support is not as important as virtual keyboard support, so sorry to bother you and thanks for the quick response.