Hello Justus, On Mon, 06 Apr 2020 14:36:03 +0200 justus-...@piater.name wrote:
> Hello,
>
> In my quest for an on-screen keyboard (OSK) for sway, the closest I've
> found are Purism's squeekboard and virtboard. They both use the Wayland
> virtual keyboard protocol. Surprisingly (to me), they affect my
> installed keyboard layout:
>
> 1. They install a session-wide keyboard layout and leave it behind, at
> least if terminated improperly.
>
> 2. Afterwards, I cannot reset my keyboard layout using 'swaymsg input
> ... xkb_layout de'; it silently runs without taking effect.
> Running 'swaymsg reload' does restore it though.
>
> The second phenomenon is surely a defect? In sway, wlroots, or
> {virt|squeek}board? Or is it just that I am trying to abuse Purism's
> OSKs outside their purpose of serving as the only keyboard present on a
> system?
>
The OSKs are meant to be universal as much as possible, and not tied to any
particular system (just Wayland).
> How about the first point? In my naive world view, the OSK should use
> any layout I tell it to use, but it should leave intact the layout of
> any other keyboard I happen to have on my system. I can attach an
> external keyboard with en_US layout to my laptop with de layout. Why
> can't I additionally run a French azerty OSK? And yet another Greek
> OSK at the same time?
>
My understanding of how layouts work on Linux is a bit different than what you
present here. I've observed that there is a global layout switch, and with
multiple physical keyboards, I found that switching the layout affects all of
them. Therefore, to make the on-screen keyboard work "as expected", I decided
to make it follow that central authority (gnome input method setting).
Following the central authority only works well when it's done consistently, so
I tied the keyboard language switch back to the system layout. This is simpler
than having a different global layout and a different layout for a single
keyboard, and hopefully spares users confusion (e.g. "I selected de in the
system settings but my keyboard is still ru").
Frankly, what you're saying sounds sensible, but I don't know how to solve it
on the application level without making things overly complicated. If you do,
then the best channel to discuss that would be the Squeekboard issue tracker:
https://source.puri.sm/Librem5/squeekboard/issues/
> I clearly lack understanding of how Wayland input protocols work, and
> hope someone over here will enlighten me. In particular, is the
> behavior I describe above intentional or accidental?
>
> My motivation is that I am trying to understand what it minimally takes
> to inject characters into applications under Wayland (specifically
> sway). For example, for my touchscreen I would like to have an OSK and
> dasher [1]. For my scripted password manager, formerly based on
> xdotool, I wrote uinputchars [2], which works perfectly for me but is
> only a crutch until I have a proper Wayland solution.
>
The solutions are the virtual-keyboard protocol
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/11
and the input-method protocol
https://source.puri.sm/Librem5/squeekboard/blob/master/protocols/input-method-unstable-v2.xml
which depends on the text-input protocol
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/19
Best,
Dorota
> Thanks,
> Justus
>
>
> [1] https://github.com/dasher-project/dasher
> [2] https://github.com/piater/uinputchars
> _______________________________________________
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
pgpZEJ2g9vuBx.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
