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.
WIP
WIP: keymap generation test passes
meta: Update features and version
WiP: cargo.lock
WIP: don't crash
WIP: no outlines
parsing: New tests
WIP: base level works
WIP: remove old keyboard
symbols correctly input
WIP: lodaing files
WIP: fallback works
Valid fallback
The C version of looping over buttons and other items was weakly typed, causing runtime errors, and also C doesn't know how to iterate in abstract, so it was full of callbacks with user-defined data. Moving this to Rust, iteration is made of simple loops, and compile-time type-checked, at the cost of some more verbose code.
Each Button has a KeyState, which may be shared with other buttons. The list of pressed and locked buttons is used as a list of keys, causing a search for the button in the current view.
Remove pre-scaling of the bounds for the keyboard and its contents.
Calculate the scale factor based on the allocation and the desired width
and height of each keyboard, using the lower value of the horizontal and
vertical scale factors.
Apply scaling in the renderer and prepare to perform centering there.
This allows us to remove a lot of #ifdef's. Either we want to use
a config.h or we don't. Since we'll want it for e.g. optional gsound
support later on let's have it.
- use G_DECLARE_ and G_DEFINE_ macros
- move all data into ClassNamePrivate
- use _get_instance_private()
This should not introduce any functional changes or breakage.
Skipped two classes (EekKeyboard and EekboardContextService) for now in
order not to break the build.
These two classes are used in some very funky WIP code that tries to
circumvent encapsulation.
(Funky code is in eekboard/key-emitter.c and eekboard/eekboard-context-service.c)
