Thank you so much @Matthew_Lee and all those who worked on the features and all those who worked on this document. (Oops, just noticed that you wrote it, it is right under the title.)
It took me a few hours and I got it all done: I took my simple touch-only Keyboard, added a new layer âcapsâ by copy of shift-layer and used the
store(&CasedKeys)
feature to put the magic into the caps layer.
Here is some feedback why it took me a few hours:
-
I do not write Keyman language, so in my Keyman Developer the Code-tab of the Layout-tab was all empty, except for some minimal stuff that some robot put there when I had clicked ânew projectâ I suppose.
-
In part 1.2, you instruct the user:
Typically, youâll want to give all letters on your shift
layer a Next Layer of default
.
Luckily, I did not do that (initially). There should be a hint, that later, in part 2.3, the Shift-layer will be copied. And there is this instruction:
Youâll want to make sure that youâve removed the Next Layer option from each letter so that the keyboard stays on the same layer.
So, it is better for users to first copy the default Shift-layer where most keys probably have got Next Layer: (none)
and only then add all those Next Layer: default
to the Shift layer. That should save dozens of clicks.
-
You tell to copy the Shift-layer and make a new Caps-layer. The âadd Layerâ window, that comes up when user hits â+â next to the Shift-layer is confusing, because we do not know that we should just enter the new name under ânameâ and leave the mysterious âmodifyer-based layer-boxâ untouched as it sorts itself out.
-
So in your document, in Part 2.2 where you introduce the store(&CasedKeys), it would help noobs like me to tell where to put that syntax. I had to search around and put it directly under begin Unicode > use(main)
. Is that good?
-
Then nothing happened in my new version, despite having added the caps layer and having defined which keys should be affected. And re-compiled of course.
-
Eventually I realized that I had to go back 15+ years in time and start writing actual rules like this:
group(main) using keys
+ [CAPS K_A] > 'Î'
+ [CAPS U_018E] > 'Ć'
+ [CAPS K_E] > 'E'
+ [CAPS K_R] > 'R'
+ [CAPS K_T] > 'T'
+ [CAPS K_Y] > 'Y'
+ [CAPS K_U] > 'U'
I propose the document should say, that even users who only create a touch keyboard must write such rules, or else the new caps-layer will only show capital letters on the keys, but will produce only lower-case output. That was rather frustrating to me.
One more observation:
In Part 2.3: Caps on Mobile, there is this instruction, which had me puzzled:
Set the shift button(s) on your new caps
layer to return to default
, the Keycap Value to *ShiftedLock*
, the Key Type to Special (active)
, and Next Layer to default
.
I found the Keycap Value
in the GUI, I found the Key Type
and I found Next Layer
. But I could not find âreturn toâ. After a long search and more read-throughs, I made a guess that by âreturn toâ the document is referring to âNext Layerâ.
This would mean that in the above instruction under 2.3 part of the sentence is redundant. I do not like âreturn toâ because it implies a simple-structure like âgo shift and go backâ. Looking at the amazing graphics with the color-arrows at the end of the document, we see that âNext Layerâ is by no means a simple âreturn toâ, could be as amazing as âshift, where no user has shifted beforeâ and then maybe shift âto infity and beyondââŚ
So I really interacted with your document and with some websites and learnt a lot from trial and error and error and error etc. and eventually I got the desired results.
This is not a criticism, it is a feedback. I guess without the document it would have taken me several days instead of several hours, or I might not have managed at all.
Thank you very much!!