How to return from Shift automatically? and how to Caps lock by double tapping?

Dear colleagues,

We are now testing the new duun touch-screen keyboard in a small group. One person asked whether it is possible to mimic caps lock by double tapping but otherwise to have the Shift-layer opened just once like with other keyboards he is used to?

  1. So tap Shift opens the shift layer,
  2. tap M produces M and goes back to the default layer
  3. tap shift 2x opens the shift layer and stays there
  4. tap shift once more again returns to the default layer

Can this be achieved?

I set the next-layer of my alphabetic characters to go back to the main layer, and made sure that numeric and math characters stayed on the same layer. This produces some of the desired effect of disabling the Shift after typing, but not the caps-lock.

Touch Keyman does not (AFAIK) currently have a built-in way of emulating Caps Lock yet, but as you suggest, a determined developer could create a CAPS layer without next-layer options.

NORMAL LAYER

  • Tap Shift once, and we go to the SHIFT Layer.

SHIFT LAYER

  • If you type a letter, it goes back to the normal layer after output (next-layer).
  • If you tap shift again, if goes to a custom CAPS layer (next-layer always undefined for letters).

CAPS LAYER

  • Typing any letter would give the capital, and stay on this layer.
  • Tapping shift from this CAPS layer would take you back to the normal layer.

One caveat is that on some keyboards (like AZERTY), SHIFT and CAPS may be different for non-alphabetic characters.

This could be done, but @Marc may suggest that we wait for Caps to be truly added as a feature.

1 Like

One thing that doesn’t work well with this solution is timing. If you are in the shift layer, and want to move to the base layer, you always have to cycle through the caps layer. For a proper solution, we’d want the double-tap of the shift to be two taps within a short timeframe to avoid this.

Yes. These kinds of things belong in the engine. Yes, I know we are under-resourced and so it all takes much longer than everyone would like.

This is documented as an issue here.

1 Like

Please see our specification for Caps Lock support on touch layouts at https://github.com/keymanapp/keyman/issues/3620

1 Like

Hi! How can I achieve this? I try with:

  • [SHIFT K_SHIFT] > set(&layer = “caps”) :thinking: but it’s wrong

You can set the ‘next layer’ on the shift key in the touch layout editor.

1 Like

You can set the layer from the “code” as in this example, and I believe it affects touch and web keyboards:

+ 'b' > 'β' layer('shift')

As Marc said, you can also set the layer from the touch keyboard configuration as in this example, and I believe it will only affect the touch layout:

"key": [
              {
                "id": "K_SYMBOLS",
                "text": "*Symbol*",
                "sp": "1",
                "nextlayer": "symbol"
              },

I’ve used both in different contexts. Most of the time, either (never both) should work, but I’ve had the best luck with option 2.

1 Like

I see this conversation is currently active.

You might be interested to know we have a range of pull requests which implement solid caps lock layer and start-of-sentence support pending for 15.0:

Documentation is on its way too:

1 Like

We are now in December 2023 and I am working in Keyman Developer 16.0.144.

I am working on an all new Android keyboard for one language. Our users will not get their soon-coming vernacular keyboard in a void: They are all using the “inbuilt” Google keyboard on their Android phones for the national language.

I am presently trying to copy the classic Gboard behaviour: The users taps Shift and gets one character from the Shift-layer and the keyboard automatically toggles back to the default layer. Unless they double-tap the Shift-button and can stay on the Shift-layer to enter their family name in all caps as is traditional here, or do other nifty things like yell at people in a chat…

I was asking in another thread about double-tap or rather multi-tap and was told that work is happening right now. We need that for a few extra-special characters to help users who are using my previous Android keyboard which is not based on Keyman.

Supposedly double-tap is already working for certain aspects, and the Shift-button was mentioned specifically here:

I have read the documention that Mark linked above:

And I found real developer documentation for casing support here:

It is just that I have not worked on Developer for over 10 years and my present keyboard is so far touch-only for mobile devices only. I am seeing in the documentation all sorts of “stores” and “groups” and whatnot and I believe that is to go into a “classic layout” where I got nothing. I am fully working in “touch layout”.

So, this might mean that I need to catch up a lot and learn about the Keyman syntax. Please just give me usefil hints. And this is important: If I write “fundamental behaviour” into the classic layout as by the “Layout” tab in the Keyman Developer for Windows, will it then automatically work also for my touch layout? Or where would I need to write my extra magic about the “Casing”?

Also I have seen that a tool was planned to copy an entire layer (Shift) to efficiently create an extra layer (Caps). And I found something when I hit “+” which is an “Add Layer window”, just the English there is very cryptic: I want to create a new layer Caps as a copy of my existing layer Shift. What do I select please in “Modifier Based layer” and what has to go into “Name”. I tried to name the new layer “Caps” but the window does not let me select “Shift” as a base to copy from. Please help.

@Martin Does this help?

1 Like

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!!

Thank you for your feedbacks @Martin. This conversation has been resolved.

One thought: the caps functionality in Keyman also provides start-of-sentence detection which is not covered here. Some of that requires a slightly different approach to nextlayer – for this, the nextlayer is controlled in the .kmn source rather than in properties of each key (so leave the nextlayer property as the ‘(current layer)’).

This is admittedly complex, but it is described, along with a working example, at Casing support on the Help site.

This allows you to do really nuanced things. For example you could have a rule: a digit followed by period keeps the numeric layer active, but alpha followed by period returns to the default layer.

I think I would like to try and do a video on this, because the devil is really in the detail!

Thank you @Marc for pointing out even more features. At the moment, I am a total re-Beginner at Keyman.

Personally, I do not muchly appreciate automatic features like beginning-of-sentence-capitalisation, because in my life, it tends to hurt more than help. One reason is that I constantly change between different languages with different rules, all day long. It is the same for the target-users for my new keyboard, just that for them it is different sets of languages.

Working for a minority language, we have many beginner-writers. For this moment in history, it is beneficial for the users to “learn” or practice the orthography rules and “apply” capitalisation to sentence-initial words and to proper names etc.

Again, it is very good to be aware of all the existing features of Keyman, not least for understanding why certain structures are in place.

We got one blessing: Ours is a fully custom keyboard with is very precisely targeted for exactly one language. So typing is very efficient, since all we need is right there on the default layer. No hopping around, no long-press, just fluent typing.

(We love all the neighbouring languages, so we have bonus-stuff ready via long-press, in case users ever want to quote something from a neighbour language or write a certain proper name.)

This gives us two layers (numbers and special) for those few really special cases, like when we need to enter phone numbers, passwords, financial stuff. I have observed that for those two layers, we often need more than one keystroke, so they “lock” until the users wants to go back to default.

In summary, I hope our coming keyboard will be very transparent and user-friendly:

  • For 90+% of shift needs, hit shift, do one keystroke and toggle back to default layer. Like Gboard and many others and like our previous keyboard from 2017.

  • For family names in all caps, double-tap shift and stay on the caps layer as needed (thank you Keyman team for this feature)

  • For special needs go numbers or special and stay until you are done, then get taken back to default.

Since Keyman provides visual feedback with the shift and numbers buttons in highlight, we do not even need much documentation, except maybe the double-tap for capslock. People will figure it out quickly.

Eventually I realized that I had to go back 15+ years in time and start writing actual rules

Yes, you have to define keys before the CasedKeys works. Interesting…I’ve never had a keyboard without at least one dead-key, so I’ve never been able to use the visual editor or write a keyboard without first defining the rules. I didn’t imagine anyone would have a rule-less keyboard.

Are you actually creating keyboards without a desktop version?

Thanks for the suggestions. What you suggest makes sense. It was an unrevised draft. I just gave you editing rights, and you might be able to fix it before I get around to it.

We recommend always including a desktop keyboard since it’s likely someone will want to pull out an external keyboard and plug it in to use with a tablet or possibly even a phone.

Yes, I am presently making a keyboard for Android only.

We already got stable desktop keyboards for years, using different tools.

And a personal note: deadkeys are dead

I used to have a mechanical typewriter, and it made sense that it had a few keys that would not move the carriage, so that we could type French.

But for contemporary users, on computers, to hit a key, get no visual feedback, then type the vowel and see the magic - just the wrong way round.

Most of our vowels do not need tone-marks. So users always type the vowel first, and they get immediate visual feedback, the vowel is there. Then - if needed - the user hits a tone-key and the tone-mark immediately gets applied to the vowel and there is visual feedback. This is also the way we all write when handwriting: vowel first, then add a tone-mark where needed.

I am not against writing a desktop keyboard eventually. I am working (always) under much time-limitation. Might do it some time in 2024, also to learn more about the tool.

I can feel that Keyman was designed (historically) from the desktop-system. And for the recent issue, it was shown again, that in theory, one can make a touch-keyboard only; but in reality Keyman has got its structures.