A redesign of popover was needed: it can no longer query the application state directly due to current state being its own actor, so instead the popover gets a dedicated copy of the relevant state.
I'm not entirely happy with the extra complexity of having an extra actor just for 1 string, but at least the duplication between C and Rust and mutual calls have been reduced.
Calling popover.show() returns control to the main loop, but squeekboard structures are still borrowed meanwhile. That's dangerous and forbidden in Rust. Therefore, this forces the return from the stack and release of the borrows before the glib main loop is invoked again.
xkb layouts are translated fine by libgnome-desktop. If not
we should go fixing there since that makes keyboard layout
strings consistent with e.g. gnome-control-center.
There weren't any 'exotic' strings in the current translations
so what we get from libgnome-desktop should be just fine.
This allows them to be translated via po so we don't have to maintain
the translation list by hand or care about empty translation files.
The only downside is that the "overlay layouts" in OVERLAY_NAMES need to
match the ones in the ui file but since a missing one is a clean crash
when selected there's little potential for subtle breackage. We could
even ensure consistency by comparing the two at run time but they change
only slowly this is not much of an issue (compared to how e.g. new
languages can be added now).
Layout type switching outside of overlay was always done with gsettings in the middle, assuming that all clicks on languages in the popover result in a gsettings event. That's a bad assumption if there's only one xkb lang present.
This is a simple work around. A better solution would be to turn the entire system of layout switching into a central object that receives messages about changes that need to be applied, and then applies them.
This commit is a bit bigger than it could have: Meson changes could have gone in separately from CI and Debian.
This commit looks more complicated than it should reasonably be. Alas, Cargo is a piece of work, and it doesn't let honest people just choose different versions of dependencies, leading to a cascade of misery. Several things were tried to curb the disaster:
- Cargo [feature] supports choosing dependencies, but doesn't support specifying dependency versions
- Cargo has a cfg() syntax in sections for choosing dependencies by build options, but it explicitly doesn't support selecting on features…
- Cargo allows choosing different dependencies based on features, so perhaps dependencies with different versions could live in stub crates pulled in as needed? Nope! If a dependency doesn't exist in the repo (and that's the point here), Cargo throws up its hands.
This means Cargo.toml needs to be generated based on the build type. More misery:
- we lose the simplicity of just doing `cargo.sh` for simple housekeeping like deps updates. HACKING.md was updated to reflect that. Perhaps that's inevitable - build options need to be like this.
- Some flaky adjustments needed in `cargo.sh` because of an additional argument that can be mistaken for an argument to the exec in `cargo run`.
- Specifying a custom `Cargo.toml` means Cargo can no longer find any tests, examples, benchmarks, or binaries, because it searches relative to the directory of `Cargo.toml`, which is now the build dir. Extra care needed to not forget about them now.
As soon as Cargo allows anything better for managing deps versions, the above should be undone in its favor.
Good side is that a couple bugs went away:
- build flags not always making it to Cargo
- arm64 builds were optional while they shouldn't
- test layouts in unit tests are loaded from an explicit directory now
The Bullseye versions of dependencies are canonical now, Buster considered legacy.
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.
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.
In order to do that, an additional piece of state (layout switcher) was exposed to the event handlers, a separation between squeekboard-only and system layouts was introduced, along with a Translation structure to prevent mixing up strings.
Pulled in some Unix-specific code from https://github.com/rust-locale/locale_config to reduce dependencies.
First reason to reduce dependencies: gettext-rs is not in Debian. Copying gettext-sys might have made sense, but the interface is somewhat confusing.
For translating a couple identifiers, detection and some hand-rolled hash map is all that is needed, and the option to move to gettext later remains.
locale_config has been stripped of the lazy_static dependency, which, messing with the strtup sequence, might be a source of debugging woes. Plus setting language once in the beginning is somewhat inflexible regarding runtime changes.
