Introduce a callback in `outputs::Outputs` that calls on every `wl_output.done`, and a dummy consumer in `ui_manager`.
This is sufficient to detect display height changes.
Parameters fudged appropriately to preserve dimensions from the original design targting Librem5:
- 720×1440 results in 420px height, via max finger size
- 1440×720 results in 360px height, via not exceeding half the display
In absence of physical dimensions, a pixel is assumed to measure half the size as on the Librem5, and then shrunk by the current display scale factor.This gives the ability to test in nested phoc at selected scale factors like before (2x being most accurate), and keeps the right size in QEMU.
The manager is used for sizing the layer surface. It promises never to exceed half the output height.
The selection of the current layout is not being done here, leading to worse behaviour in 1:1 scaling.
In the future, it could be used for sizing the keyboard itself and the suggestion box, as well as decide which layout to use, because layouts should have some sizing hints.
Control and Alt are special in that they aren't expected to switch levels, and so don't need to change what characters are output.
Use in layouts by adding `modifier: Control` or `modifier: Alt` in place of `text: "foo"`.
The latching of the modifier will force the keyboard to emit raw key presses and prevent it from outputting text.
Erasing with zwp_text_input_v3 version 1 requires bytes, and bytes require get_surrounding_text. That, however, is optional. That's a mistake in protocol design.
Easiest to drop this until the mess is solved on the protocol side.
gio::Settings::set_value takes over ownership of the Variant sometimes, but in other cases it doesn't. To prevent this being a problem, the custom Variant is made of the type that will never have its ownership taken.
This is not necessarily consistent with what gtk-rs authors intended.
In practice, the ownership is shared by refcounting, and after the Rust reference is dropped, one taken by Settings survives.
Locking is not determined by button state any more, but rather based on the view active at the moment. If pressing/locking a key results in the current view being active, the key is active. If locking a key results in the current view, the unlock view is activated.
This ensures that the layout type information is accessible to the state manager when new layout information arrive.
The should be thought of as a stopgap measure. A proper solution would be to separate the state properly, and probably turn layout information coming from random places into messages that some object (thread?) collects and displays.
This adds sugar for logging `Result`s with a handler, makes names evoke something closer to "logging" than "warning", tries to remove any redundant `Logging` where the module name will do, and introduces a type strictly for bad things happening.
