Apologies in advance if I’ve missed this in the keyman documentation. I would like to define 3 touch layouts for the platforms “tablet”, “phone”, and then for an “android phone”. The first two are available in menus, how would “Android Phone” be indicated in the touch layout JSON file? Is there documentation for the JSON that I’ve overlooked? thanks!
Hi @dyacob ,
I’m a power-user, not a developer. I’m curious what keys your Android KB and iOS Kb have different, arrow keys? First, I’d like to say that I don’t think Keyman supports what you are trying to do. With that said, here are 3 ways you might be able to make it work.
–CSS Route–
You can use CSS to give a different appearance to the same keyboard in Android or iOS, and phone or tablet, but very few Android devices trigger the Tablet flag. I understand that this is not what you want.
With some clever use of CSS you might be able to add all possible keys and selectively hide different keys on the different OS’s.
.ios .kmw-keyboard-sil_cameroon_azerty #default-K_QUOTE {display: none}
or
.phone.android .kmw-keyboard-sil_cameroon_azerty #default-K_PERIOD {display: none}
This is likely to crash Keyman or make typing unpredictable, especially if the key widths are different.
–Layout Route–
While you could create ‘android-phone’ as a layout under your keyboard as you want to do, I don’t know how you’d trigger the right versions from Android and iOS. This probably won’t work in current versions of KM Developer.
–Keyboard Compilation Route–
If everything worked as expected, you should able to create 2 separate keyboards with different keys, and then check IOS for as a target for one and Android as target for another in Developer config. These keyboards could be bundled together in the same package.
But since all of the mobile keyboards use the same JavaScript code, I think the platform flag doesn’t restrict the output and so I don’t think this would stop the devices from loading the wrong keyboard…and this doesn’t really help you to target phone and tablet separately.
Thanks @Matthew_Lee . My interest to have a slightly different Android vs iPhone layouts stems from limitations with the longpress popup presentation. The popups in iPhone appear to be limited to 2 rows, then options get truncated off. Whereas Android has been able to present 3 rows without issue. I’ll try ‘android-phone’ as a keyword and your suggestions.
thanks!
Note that I said that you could create the variant, but you would have no way to trigger it. Don’t waste your time…I’m pretty sure you will have no way to choose android-phone in Keyman. The only one i was suggesting that you try was the CSS one, but that won’t help much for popups.
The KM developer team would have to add a new feature to recognize android-phone as a specific thing…and that could take some time even if they decide to.
Long story short, tablet is not triggered reliably, and you have no control over which layout a device chooses. Your new layout will be forever hidden.
If this is a limitation for you, let’s explore how we can address that – it would be better than an unsupported workaround 
We generally suggest limiting the number of options in a long press popup, because it gets really hard to pick the right letter as part of a single gesture when too many are presented!
On iOS, we limited popups to two rows due to the way that iOS parcels the screen into keyboard and non-keyboard regions; Android has fewer limitations in how the screen real estate can be used so we were able to do more.
Thanks @Marc , I’ll explore some other options. Other than a short press and longpress, are there are other touch types detected by keyman?
If you have a large number of diacritics that stick to a large number of letters, you could try a diacritic row instead of a number row. This is done in the Cameroon Keyboard, so I don’t need more than one or two characters per popup. It seems far more natural to me than searching through popups.
Of course, you will need to make sure that your keyboard produces composed or decomposed combinations as desired. Also, if your orthography disallows certain combinations, you might want to stop those.
Thanks Mathew, I like the diacritic row approach. in the case of a syllabary, i would want the keys of the extra row to dynamically update to display the options -sort of like a popup area fixed on the keyboard . At least one Amharic keyboard app (“fyn” I think) takes this approach, so it’s not as wild as it may seem.
Interesting…so ‘fyn’ changes the layout based on the deadkey that is pressed. That sounds…complex (But I’d like to see it).
In the Cam keyboard, the diacritics are typed after the letter which is shown in the target text box, so there is no need to update the diacritic row in my setup. It is the same with the desktop keyboard; nothing is hidden.
a + ` = à
Typing decomposed characters after the base character also makes it easy to stack diacritics if needed (ex: nasal and tone).
I experimented with a multi-layered Keyman Amharic keyboard – but never took it through to completion – which did some of this.
- Presentation from Unicode conference IUC38
- Very experimental source (based on gff-amh-7)
Basically, you have 34 or so custom layers – each one being the base layer in the bottom four rows with the alternate forms for the most recently pressed key in the top row. It sounds like a lot of data but would be easy to generate (but painful to do by hand I expect). Given the touch layout format is just JSON, it should be easy enough to write a script to generate the 34 layers.
The experimental source shows this for just the d key – but is certainly incomplete even for that (it was really built for screenshots). If this is of interest to you, I’d be happy to schedule a meeting to do some exploration of the concept – I can assist with the Keyman technical areas while you handle the orthographic side.
1 Like
At this stage, no. A flick (swipe down) is anticipated in an upcoming version, but we have not defined how it works yet. We may allow flicks in multiple directions, but we’ll have to experiment with the model before we can be sure how it will work.
Note that the more touch gestures that a keyboard includes, the less intuitive it will be to new users – it can be important to have multiple ways to access a letter in that situation.
For some other examples of syllabic-style approaches being taken:
The green keys have diacritics that can combine with nearly any of the other letters.
I don’t know this language personally, so my understanding of the design decisions here is limited, but this is probably one of the more complex keyboards in this direction. Selecting many of the left-hand side characters will change layer in a manner similar to what was spoken about before.
After selecting the second row’s fourth key (which is highlighted in green below):
1 Like
This topic was automatically closed after 14 days. New replies are no longer allowed.