Draft: proof of concept hacks to calculate the height better
The previous code which calculated the height of the keyboard used hard coded values for a key height, and the number of rows in use. This resulted in the keyboard dimensions being wrong on devices with different physical scaling than the Librem 5.
This replaces that code to try and calculate the height based on the actual layout in use, it picks sensible limits based on the physical display dimensions and then scales up the layout to fit. This is not a perfect solution, as the layouts are pre-computed and scaled up at render time, making it impossible to fix mismatching aspect ratios by adjusting the row or key spacing.
Issues:
- The proper layout isn't always loaded, e.g. the number layout isn't loaded on a number input, so the calculated height will be wrong.
- Different layouts change the keyboard height. Whilst with the layout changing in the next commit, the physical locations of the base keys is preserved when switching to the terminal layout, having the keyboard height change depending on the input box isn't ideal. It would be better to set the height based on the tallest layout, and adjust other layouts to fit. I suspect this is how Gboard does it.
- Loading the layout in get_preferred_height_and_arrangement is awful jank. This needs to be reworked and implemented properly.
- Landscape causes the layout to be stretched, not great a11y
I think these issues can all be fixed with two (albeit big) changes:
- By moving to a layout system which allows for dynamic adjustment at render time.
- By parsing all layouts and user configurations to determine the keyboard height during initialisation, based on the max layout height.
This lets the keyboard height then be determined for a particular combination of device, language, and some user defined offset. The layouts can then use this to define the row and key spacing, key sizing etc. Some special handling will be needed to keep the absolutely key positions correct between the text and terminal inputs.