Due to the way the panel size is calculated, there might be a small
empty space on the sides or top of the layout. This can be an issue,
especially when this empty space is located on the sides, as touch
events in this area are not taken into account.
By allowing a small difference in horizontal and vertical scaling, we
can ensure the panel occupies the whole display width in cases where
this would be problematic.
The layout for this keyboard exists, however it isn't present in
`resources.rs`, making it unavailable.
Signed-off-by: Arnaud Ferraris <arnaud.ferraris@collabora.com>
Even though proper size management is being worked on, this patch
proposes a simple and easily revertable solution to device-dependent
sizing issues.
First, it provides different calculations based on the display
orientation. In landscape mode, this allows us to have a sensible
keyboard size while leaving enough screen estate for apps to be able to
display useful information.
Then, it gets rid of the weird calculation for display widths between
360 and 540px. While having some continuity is a pleasant idea, in the
real world in doesn't work, as shown by port attempts to other devices:
a 480x800 display (scale 1) would show an unusable 190px-high keyboard
(about half the size of the Librem 5 on-screen keyboard on a device I
own).
Finally, this commit makes sure we never use a hardcoded size.
Tested on the PinePhone, PineTab and Librem 5.
Note: Current behavior is preserved on the L5 in portrait mode, but
keyboard is a bit smaller in landscape mode; this is deliberate, as it
was previously using too much space (causing some apps, such as chatty,
to be unusable).
Using the actual monitor width in pixels can lead to unsatisfying
results, depending on the display orientation and physical size: on a
10" tablet with a 1280x800 resolution (scale 1), portrait orientation
will be using the narrow layout.
If the keyboard is sized in an optimal way (i.e. so the layout fills the
whole area, with no blanks on the sides) this would result in an
unnecessarily huge keyboard being displayed, therefore wasting screen
estate.
Using the virtual display size gives a hint about the physical size of
the device, and can be used to select wide layouts even in portrait
mode, while still preserving current behavior on HiDPI devices.
This has been tested on PineTab, PinePhone and Librem 5.
This commit changes the layout of the `eschars` view, in an attempt at
making it more logical and optimized to reach more frequent symbols more
easily.
In order to stay consistent with other layouts, the bottom line has been
re-arranged and keys dimensions have been optimized (based on the
`terminal` layout, which has similar features).
Furthermore, the ç/Ç keys in the 'normal' views have been replaced with
./, so that all diacritics are on the same view.
This commit also fixes the Backspace key behavior.
Due to an excessive amount of keys in the `eschars` view, one of the
rows would overflow the screen. This commit removes the `Ç` key, which
is already present in the `upper` view.
A number of keys would not give the expected result, due to the lack of
a `text` of `action` property. Additionally, the layout wouldn't load
because of an old file format (it seems `bounds` are not supported
anymore).
This patch makes sure this layout can be loaded and used by squeekboard
v0.1.9.
