Capslock state vs shift state


#1

Hello,

In mac, installable keyboard layout shift state and caps state are treated different. This gives additional state for alpha keys.

https://developer.apple.com/library/content/technotes/tn2056/_index.html

Even in microsoft KLC, shift state and caps state are different.

But in keyman shift and caps state is linked. This is true for Roman letters. For all indic languages, there are no caps letters. But there are huge set of characters.

If we break the shift and caps state, we can map more letters uniquely to QWERTY keyboard.

Please review and advise.

Thanks,
Mayura


#2

Keyman keyboards are able to map caps lock state. There are three states for Caps Lock checks:

  • ignore caps lock state, e.g. + [K_A] > ...
  • test caps lock on, e.g. + [CAPS K_A] > ...
  • test caps lock off, e.g. + [NCAPS K_A] > ...

Additional reference on modifiers and state keys:
https://help.keyman.com/developer/language/guide/virtual-keys

See also: https://help.keyman.com/developer/language/reference/caps for additional Caps Lock functionality.


#3

Thank you.
I want to use Caps lock as a “Second Shift”.
I want a three state of keys for all alphabets and numerical.
One for normal state, one for shift state, one for Caps lock state.
Another feature I need for caps lock to function as “Second Shift” is; as soon as the letter or number is typed in the “Caps Lock” state, the “Caps lock” should get released just like “Shift”.

store(&capsononly) “1”
store(&shiftfreescaps) “1”

With above setting, although I get “caps” state different from “shift”. I have to press "shift to release the “caps” lock.

In need to release the “Caps lock” as soon as the letter is typed in the “Caps state”

Please assist.


#4

Keyman does not have the ability to release Caps Lock in the way you describe.


#5

Thanks for the clarification. Could we do a feature request, either we get a variable to enable this feature
or
a way to turn off the caps lock in the keys sequence.

This way we can set the caps lock to OFF after certain letter is typed.


#6

Sure, feature requests can be submitted on GitHub at https://github.com/keymanapp/keyman/issues/new


#7

Thank you. I have posted a feature request.


#8

How about setting up CapsLock to trigger the AltGr state instead? Is that possible?
It would have the added benefit not “locking” so it would really act just like a 2nd shift.


#9

@Jolene, that’s an interesting idea. I’m not sure how portable or possible it would be without some investigation. If you can demonstrate a good use case, please feel free to open a feature request at https://github.com/keymanapp/keyman/issues/new


#10

I was actually thinking of this as a solution (albeit late) for mayura as it should work already in the current version of Keyman. At least that is how I understood the documentation you provided a link to regarding virtual-keys. At the very bottom of that page it states that “Any key can be used to switch keyboard layers” and then lists 5 layers with values 261-265 (AltGr being 265).
So, I’m assuming that CapsLock can be ignored (as described on the other page) and can be used to switch to the AltGr layer.

However, the topic of additional modifier layers is one that I’ve developed a personal interest in.

I also predict that there will be an increasing demand for multi-script keyboards- not just the ability to relatively easily switch keyboards. Much like the Japanese (and Korean) keyboards. Thanks to what Unicode offers in terms of facilitating mixed-script text combined with globalization which is quickly reaching and beginning to transform every remote corner of the planet, it seems inevitable to me that we will begin to see more and more mixing of multiple writing systems, not merely in the same document but within the same paragraph and even sentence. Especially with Latin being one of those; particularly in regions whose official/native languages are written with a non-Latin scripts. There are numerous reasons for why this will be more and more commonplace. Switching keyboards in these instances, will be cumbersome and I foresee that users will prefer and seek other options.
The most logical and obvious of those, in my opinion, will be to re-purpose the Caps Lock key (which has fallen into disuse by the new generation at-large; even when typing in all caps for the most part!). It is particularly suited to the task because it even has an LED indicator on most keyboards, and this functionality is also quite intuitive: it momentarily (with LED reminder!) reactivates the original, native functionality of the underlying hardware. And it actually natively supports (at least) two states—the base layer, and the standard shift layer—exactly like the underlying hardware. Windows only supports separate mapping for CapsLock and CapsLock+Shift; but Mac allows a complete doubling of any/all modifier states and *nix-based systems with XKB offer even more robust and creative mapping options).
While this may not immediately seem intuitive to many computer savvy adults, my anecdotal experience and informal research shows me that newer computer users whose native languages use non-Latin scripts, as well as the younger generation of the West who generally ignore CapsLock do in fact find this alternate re-purposing of Caps Lock to be very logical and intuitive—because they have no prior experience or information which contradicts such functionality.
However, this particular capability does not seem to be particularly easy to implement with Keyman. Actually, if I’ve understood the documentation correctly, it may not be possible at all to duplicate this functionality.
And that is actually a feature which I intend to request, because I think it is — or at least will become — a serious deficiency of Keyman (that is unless I’ve misunderstood the documentation-I didn’t see any explicit confirmation that it is possible to have a unique layer not only for CapsLock—separate from the base or shift layers—but also an additional layer with CapsLock AND shift which is also unique from the base layer, the shift layer AND the CapsLock layer. If that explicit confirmation is indeed present, I somehow missed it or it was not on those particular pages. If it was assumed to be understood as “implied” or “obvious”, I would assert that while such an assumption is presumably reasonable for someone who has a background in IT and/or software development, this is actually not, in fact, sufficient for the average end-user; even a fairly savvy power-user).


#11

sorry what is AltGr?