We have two layout here in Keyman for this language (Obolo): The CHWERTY and QWERTY layout
The CHWERTY layout produces “Ch Sh Ọ N̄” with SHIFT but produces “ch sh ọ n̄” when capslock is on. This means that many keystrokes will have to go into typing this diagraphs in all caps, and right now, this keyboard cannot type those diagraphs in all all caps unless each letter is taken singly.
Using the QWERTY layout helps, but will only solve the problem of CH and SH since one key outputs one letter, but “ọ n̄” will still be in lower case with CAPS LOCK on.
Also, in the language, the QWERTY layout overloads ones right hand and makes it do more work while the left does less. That makes one tired typing long articles (because the most frequently occurring letters are all on the right).
Since you (Keyman) would like us (keyboard authors) to minimise keystrokes (and we know that all keys are useful), is there no way for you to instruct the Keyman app to “output every letter in the upper case equivalent when CAPS LOCK is on”? I think that will really help to reduce multiple keystrokes and speed up writing.
Or, is there something I’m not doing right? Any workarounds?
IN SUMMARY: I want to be able to use this keyboard with “caps lock on” to type those diagraphs etc. in upper case when writing titles, etc.
P.S. I’ve checked all the topics relating to caps lock in this forum.
First, just for clarity on our end, what platform are you using Keyman on? Based on your description and the screenshots above, I’m guessing Android, but it’d help us if you could include those details.
Since you (Keyman) would like us (keyboard authors) to minimise keystrokes (and we know that all keys are useful), is there no way for you to instruct the Keyman app to “output every letter in the upper case equivalent when CAPS LOCK is on”? I think that will really help to reduce multiple keystrokes and speed up writing.
Every now and again, we internally have a discussion regarding potential designs to address this, but sadly this keeps falling further and further behind on our roadmap.
So… it’s something that everyone would like, but it simply isn’t something that KeymanEngine does on behalf of keyboard designers… at least not yet.
If you want a keyboard to provide this behavior, there is a way to do it, though it does mean adding a lot of extra detail to your keyboard. This post describes the general approach you’d need.
so in theory you need to support ch, Ch and CH as well as sh, Sh and SH
there are a few different strategies that could work:
avoid using digraphs on keys, use separate s, c and h keys to type digraphs, or
on mobile devices have separate layouts for lower, upper and titlecase, with buttons to switch between them as required, or
on mobile devices have two layers: lowercase and titlecase and add CH and SH to longpress of Ch and Sh respectively
there are also many other ways of handling it as well, by writing more complex contextual rules and constraints to guess whether uppercase or titecase should be used.
This issue affects the desktop app, but I’m posting from Android that’s why the picture is Android screenshot.
I have read that post before publishing the last update to the keyboard. But that did not address my CAPS LOCK issue. At the end of that post you see this:
“This could be done, but @Marc may suggest that we wait for Caps to be truly added as a feature.”
Again that post is about switching layer, whereas this one is about CAPS LOCK producing lower case letters.
I have already done that in the QWERTY layout. But the problem with that layout, as I stated, is that it overloads ones right hand. Note that it’s the only available keyboard for writing this language. So we use this keyboard to type long articles in the language. If you have to type that long, then both hands will need to share in the work. Thus, the CHWERTY layout does it better in this language. But then, this CAPS LOCK issue is affecting this CHWERTY layout.
Even if I avoid using diagraphs, the ọ and n̄ will still appear in lower case with CAPS LOCK on.
That’s exactly what I’ve done. But it doesn’t solve the CAPS LOCK issue. If you need to try out the keyboard, I can send you the link or the .kmp file.
@joshua_horton and @Andrew_Cunningham
I really appreciate the work that you and the Keyman team are doing. It’s highly appreciated. For this language Keyman is a life saver. I just wanted you to know that fixing this issue will really help.
I assume that Ch and Sh are more often needed to be typed than CH and SH in which case one possibility is to have Ch and Sh generated on the shift state and move CH and SH to AltGr sequences for instance.
Rules tailored for CAPS and NCAPS states should allow you to control the desired behaviour.
For a couple of keyboard layouts I developed I was in the position to have to type long documents in them. In one case a minimum of 80 pages in a single document.
After analysing the orthography in more detail a number of optimisations suggested themselves.
Extensive typing in a language is a good way to stress test a layout .
Normal state is lowercase, shift state is title case and AltGr is uppercase and disable caps lock.
Normal state is lowercase. Shift state is title case. Caps lock becomes a toggle making keyboard give lowercase and uppercase.
There are other options. But really comes down to how users want it to behave. The more you move from the default behaviour of a keyboard, the more complex the rules become, especially if the touch and physical keyboard paradigms differ.
Keyman can be quite powerful and quite sophisticated keyboard layouts are possible.
But line 159 is important. It is intended to help check wrong placement of accent, and other things which are not acceptable in the orthography, which will also help users to write well. Any workaround for “notany” please.
Yes, notany is something that we really want to support in KeymanWeb better. We have a plan for it but have not had the capacity to resolve it yet. I am going to try and shuffle some priorities around and get this resolved in 14.0. See https://github.com/keymanapp/keyman/issues/917 for details and some partial workarounds.
