There are some hacks here in the form of an extra field "appears_locked_from", which can be used to hint that the user should see the button as locked. Without it, there's some confusion on user side regarding buttons that change states unprompted.
The builtin file path is embedded in the binary and subject to substitution, which makes it invalid when trying to build a .deb reproducibly.
Out of the two solutions, it's easier to make the change here rather than customize .debu building not to run tests reproducibly.
If you have a keyboard layout like the following:
A B C D
E F G
H I J K
The E and G keys here should be pressed when clicking in the empty space
next to them. This is achieved by not checking the bounding boxes of
each key and instead just using the button and row offset to extend
buttons/rows to the edges of the view. Caching for the size and
position of rows is introduced to simplify implementation and possibly
improve performance.
Fixes#191
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.
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.
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.
Sizes of widgets can be derived, so storing them was only for C compatibility. Similar with storing position inside of widgets.
Some layout margin and scaling changes could be introduced, meaning a possibility of visual differences.
