This actually removes the size request from panel creation. Incidentally, this still works becuae the following configure event gets the sizes from glib.
The library is small and simple enough to be considered "finished". In addition, it doesn't seem to be shipped by Debian.
In relation to its usefulness, it's little effrt to copy it.
This will help make the init procedure safer, by limiting the number of Rust objects that need to be carried to the C side and may be mangled on the way there.
The second benefit is that it allows outputs to become part of new state management.
This reverts commit 5c1b28e4ed8b046a251609e5f7db4b4df9e710f5.
It has only been needed to move Rust structure across C bridges. That's unneeded with more integration.
This ensures that the new state machine is fed events, as well as that its results are applied.
The old ad-hoc system is removed.
There is one regression where the last layout will be used when the panel is brought up manually.
Handling visibility state ad-hoc has shortcomings in testability and locality, and this module attmepts to rectify that by creating an explicit state machine, along with a loop to drive it.
Actually applying state is not implemented here.
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.
Handled via po. Remove now empty files. The match with resources.rs
shows that some of them weren't even used (e.g. fa-IR) showing why a
switch to po is useful (which allows to maintain us that outside of
code).
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).
