Having done a first test with the touch-screen (without lexical model at first) and having compiled and created a keyboard app with KAB, this is the result produced:
On the left is the Amharic keyboard from the keyman developer 13 documentation, if you look at the height of the keys, the Amharic keyboard is much more spacious, the keys are higher.
Yes, the right keyboard does have a 5th row, but does that mean everything gets squashed ?
So my question is, next to the padding we can add or not add for width, what provisions are there in the design to control the height of the keys?
Yes, so at this point, the height of the keyboard area is fixed. This is something that is under evaluation for future versions. Agree that five rows feel a bit squished!
That is too bad. I would say that is a major put-off for useability. Would it not be possible, like now it is possible to add the number row in android as an extra row, to have an option “allow for an extra line” in keyman ? If indeed you are advocating language based keyboards to be developed this seems to me like a (very) high priority. So if you can put it up there in the top 5, or even higher, that would be great.
While you are limited to the size of keys when you have so many characters to access, have you considered using longpress keys or multiple keystrokes so that you can reduce the number of keys on each layer? So, a longpress on “e” might allow you to access any of the accented e or epsilon keys. Or, typing two keys “;n” to access the eng, etc.
Another option would be to remove “q” or “z” or whatever characters aren’t not used in the language and put them on another layer where they are still accessible when needed, but you put the more commonly used characters on the main default/shift layers.
Thanks for the feedback Lorna, Yes there are a few tweaks possible, but they only influence the width, whereas really, the keyboard needs some more air in the height … The letter e is actually a bit rare, whereas ɛ is much more frequent. We wanted this keyboard to be easy to use and not having to use the longpress every other letter, so that is the reason these have what I call front row seats.
Of course we are advocating language based keyboards to be developed – that’s all we do! But priorities for functionality requests are tricky. We have many competing priorities and we are extremely resource constrained. This feature would likely take effort from 3 people on the team who are all over-committed as is, so I cannot promise that we can deliver it as quickly as you’d like it.
I see you’ve opened issue #3225 on GitHub (thank you!). Please encourage other people to ‘vote’ for the issue (using the reaction face icon) so we can understand the community demand.
I have tentatively put this into the development cycle for 14.0. I don’t know if we will achieve it because of the other issues we have yet to complete.
