Handle "docked mode" as expected
"Docked mode" doesn't adequately cover what this is about, but at this point it's the most descriptive.
This is about the interaction of various OS components, in order to give the user some input it expects. Part of this issue is to define what the user would expect.
Physical and virtual keyboards
In "docked mode", we define user's interaction with the L5 as if it was a laptop. That means a full physical keyboard.
In this case, the input method should mostly keep its general input panel(s) hidden, because they would be redundant. That includes not showing them when application requests an input method.
In phone mode, the on-screen keyboard may be the only way to input text, so it should be automatically shown, and in case of legacy programs, the user should have a way to bring it (e.g. via shell button).
Details
What we really care about is redundancy, so a physical numpad-only does not collide with a qwerty on-screen keyboard. So in this setup, for the purpose of text fields, we're "phone", and for the purpose of number fields we're "docked".
In several cases, users might find the on-screen panel more useful than physical:
- handwriting
- button labels adjusting according to what's written (upper/lower case, whatever it is called that's like ligatures)
- mismatched labels on the physical keyboard (emoji is in this category)
- more buttons available
Consumers
Docked mode should be communicated at least to the input method (to let it stay hidden), and to the shell (to show the keyboard override button, and to show keyboard indicator).
The compositor needn't know. While it sounds tempting to disable text-input protocol, this is moot because of for example non-Latin inputs.
Policy
From Details section, there are two kinds of policy sources:
- user preferences
- comparing the physical and on-screen input abilities for redundancy (taking script into account)
User preferences can be communicated to any of the input method, shell, or compositor, and relayed easily.
The physical input capabilities are fully known by the compositor, but can be relatively accurately relayed anywhere. wl_keyboard
already partially serves that and is builtin.
However, only the input method knows exactly what capabilities it has, due to the free-form nature of the medium. This makes the input method the ideal place for determining whether input panels should be visible.
Implementation
To turn the input method into the policy place, there need to be ways of communicating a bunch of things:
- initially the number, and later the capabilities of physical keyboards from the compositor to the input method (probably Wayland protocol)
- whether the input panel is redundant - the input method tells the shell (probably d-bus, although ideally it would respect Wayland seats)
Caveat: to be 100% sure about redundancy, we need to always know that the keyboard is full (I believe keyboards don't advertise if they have a numpad), and failing that, always know the text field type (we don't, text-input is not universal). So it's reasonable to give the user a way to being up the on-screen panel anyway even in docked mode. (if we insist on making the override button disappear, a gsetting maybe?).