I have three layers in my keyboard: default, shift, and caps. I can navigate between them just fine, but the output of the caps layer is lowercase.
My code:
- [K_G] > ‘ng’
- [SHIFT K_G] > ‘Ng’
- [CAPS K_G] > ‘NG’
When I type the [K_G] key in the shift layer, I get ‘Ng’, but I get lowercase ‘ng’ for both default and caps. This happens with both ‘(current layer)’ and ‘caps’ as the modifier for [K_G] in the caps layer.
If I change the modifier to ‘rightalt’, and put the code
- [RALT K_G] > ‘NG’
then I do get ‘NG’ in the output, so it seems to be specific to the caps layer/modifier.
Hello @kmshames
It should work from what you are explaining, but we would like to take a closer look.
What is the version of Keyman Developer? We test your rules using Keyman Developer v-16.0.147 stable and Keyman Developer v-17 beta but it is working as the rules stated.
Could you clarify that on Layer “caps” of the phone platform with the key that has ID set to K_G is using the Modifier: caps? (See image below)
The only thing that is stopping us from outputting “NG” is not assigning the Modifier to caps.
We could not reproduce what was described but would you like to send the keyboard package in a ZIP file for us to look into?
Let us know how we can assist.
My mistake - the keycap’s ID code was actually changed to [T_NG], not [K_G]. The [CAPS ID] rules seem work fine with [K_?] codes, but not with [T_?] codes.
So my rules are
-
[T_NG] > ‘ng’
-
[CAPS T_NG] > ‘NG’
caps layer + press [T_NG] = ‘ng’
-
[K_D] > ‘nd’
-
[CAPS K_D] > ‘ND’,
caps layer + press [T_D] = ‘ND’
Hello @kmshames
Would you be able to provide some screenshot and/or the keyboard package if the following explanation does not fix the issue?
There wouldn’t be much of a difference between the two.
As long as the ID is set to T_NG or K_G that has the rules specified in code in the Layout tab as shown here:
Touch layout tab
Then the output is going to use the rule to get to NG for the corresponding keys.
This would be a different conversation if the keyboard were for Windows or if there are more rules than what we gave as an example.
We hope this gets to the bottom of the issue.
Hi,
Here are some screenshots, and I’ve attached the zip:
teclado_itunyoso_triqui.zip (30.3 KB)
(the package might have two keyboards in it, the correct one is the one called “Keyboard”)
Hello @kmshames
We’re happy to have a solid solution for the issue. Here is the keyboard package (30.3 KB), we apply changes to the 100 lines of code or so, feel free to apply the changes to the rest of the code.
It turns out that &TARGETS, &version, and not specifying NCAPS are the main causes for the issue. There is no need for applying caps into every keys in the Modifier in the Touch Layout tab. This is what should be done instead:
store(&version) and store(&TARGETS) must include the following:
It’s recommended to use version 10.0 as it is the version that caps layer was first supported and we managed to get the rules to work by using ‘any’ as the device target.- Be sure to add
NCAPS for every non-cap keys as shown below:
- Hopefully, you can see the result just like this:
Here are a few essential Keyman’s articles that would enhance your keyboard development journey:
- How to resolve CAPS and NCAPS ambiguity in Keyman keyboards – Keyman Blog
- Using &CasedKeys
Enjoy using Keyman Developer!
1 Like
Thank you for the help! This has fixed the [T_?] keys, but the [K_?] keys are still outputting lowercase on the caps layer. Will I need to add rules for all of them?
I’m not sure why this is happening - the [CAPS K_?] keys work just fine in another keyboard, so it must be something particular to this layout.
I was able to fix this with this code:
Which works for everything besides AEIOU. It seems that what’s breaking those keys is these rules, which are used to accent vowels:
If I comment these out, then the workaround at the top of this post works for the vowels as well (although I do need these rules as well eventually).
I was able to make this work by adding the following lines:
- [CAPS K_A] > ‘A’
- [CAPS K_E] > ‘E’
- [CAPS K_I] > ‘I’
- [CAPS K_O] > ‘O’
- [CAPS K_U] > ‘U’
So my keyboard is working now with those workarounds.
Hello @kmshames,
We’re happy to see the progress. There is an improved way to do this with the links mentioned above; feel free to check them out for more explanation.
This is the solution to the issue:
store(&CasedKeys) [K_A]..[K_Z] [T_EE]
+ [K_A] > 'a'
+ [SHIFT K_A] > 'A'
+ [K_E] > 'e'
+ [SHIFT K_E] > 'E'
+ [K_I] > 'i'
+ [SHIFT K_I] > 'I'
+ [K_O] > 'O'
+ [SHIFT K_O] > 'O'
+ [K_U] > 'u'
+ [SHIFT K_U] > 'U'
c deadkey grave + vowel = grave vowel
+ [T_EE] > '´' deadkey(grave)
+ [SHIFT T_EE] > '´' deadkey(grave)
c + [CAPS T_EE] > '´' deadkey(grave) c there is no need for this anymore
'´' dk(grave) + [K_A] > 'à'
'´' dk(grave) + [K_E] > 'è'
'´' dk(grave) + [K_I] > 'ì'
'´' dk(grave) + [K_O] > 'ò'
'´' dk(grave) + [K_U] > 'ù'
'´' dk(grave) + [SHIFT K_A] > 'À'
'´' dk(grave) + [SHIFT K_E] > 'È'
'´' dk(grave) + [SHIFT K_I] > 'Ì'
'´' dk(grave) + [SHIFT K_O] > 'Ò'
'´' dk(grave) + [SHIFT K_U] > 'Ù'
'´' dk(grave) + [CAPS K_A] > 'À'
'´' dk(grave) + [CAPS K_E] > 'È'
'´' dk(grave) + [CAPS K_I] > 'Ì'
'´' dk(grave) + [CAPS K_O] > 'Ò'
'´' dk(grave) + [CAPS K_U] > 'Ù'
This is the result:
Let us know how it goes.
