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.
Layout management was pointlessly bound with the EekboardContextService with inheritance. Splitting it out will make it easier to further break apart layout state management, settings, and input method in the future.
