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.
