State Scheduling Triggers

[jbondeson]

KLL 0.5 Identifies several un-implemented State Scheduling mechanisms

• Press
• Unique Press
• Unique Release
• Release
• Hold
• Off

[kll]

Is there any rough planned time frame for when this feature might get some attention? I'm really interested in the new Kira but simply can't buy yet another keyboard that will end up sitting on the shelf not being used because it lacks this one basic feature. I think it would even more important on the Kira since it lacks the RGui and App buttons which are frequently used as function keys.

[haata]

My current guesstimate would be around June is when I'll have something basic working. I've been working hard to get all of the major bugs fixed (which I'm pretty close, maybe a week, to finishing).

For Kira, the main feature I have to get ready first is the indicator light (e.g. handling caps lock and layer lock triggers).

[kll]

Awesome, thanks for the update.

[kll]

Congrats on the successful Kickstarter campaign! I got in on an early bird Kira Metal. Looking forward to using it with this feature in October 😛

I've got a K-Type and Infinity Ergodox I can test with whenever its ready for testing.

[haata]

:D

It may not seem like it, but I'm getting much closer to getting this working.

[simonwillcock]

@haata how's the progress on this one going? Anything we might be able to help with to get this ready? I'd happily help test things (have an Ergo Infinity)

Thanks for your hard work!

[dmgm]

@haata said on discord a couple of weeks back that it was like priority number two. My words but sounds like it must be close. Perhaps he's hit a snag. I'm waiting for this also. Dont want to need to work out how to use QMK yet.

[haata]

I finished up the locale stuff (ended up having to de-couple the kll compiler from the controller repo, which was a lot more work than expected).

And, more importantly, I've started work on State Scheduling today (and it's at the top of my list!). The first rev will likely exclude things like Unique Press/Release and Isolated Actions, but those aren't too hard to implement so I wouldn't expect much of a wait between.

Right now I'm just figuring out how I'm going to test "unclosed expression". These weren't possible before. For example:

U"A"(P) : U"B"(P);

That means, when you press A, B will be pressed. However, when you release A, nothing will happen. Which will results in lots of bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb's until something happens. Such as:

U"B"(P) : U"B"(R);

Which will close the original expression.

Testing for this needs to be automated for two reasons:

1. HaaTa is too lazy to test infinite permutations by hand
2. Users should be given a warning/error when an expression is generated that cannot be closed.

Fortunately, I don't think this will be hard. I can just go through all the possible Results and make sure there's a corresponding P and R for each expression used somewhere in the layout.

[dmgm]

Excellent news.
My use case was to use a key as a modifier when held, and a key when pressed and released.
I wanted to emulate the feature I've seen elsewhere of Caplock acting as left_control when held and escape when pressed and released.

As an emacs user I'm wondering now if holding "c" could actually work as "control + c" which would simplify a lot of common keystrokes.

[apazzolini]

As an emacs user

Well there's your problem :p

Seriously though, it's awesome to hear progress is being made on this. I emulate caps lock to esc/ctrl with Karabiner, but there's no Windows equivalent for it. Really excited to be able to do it on the firmware level and get the dual key support on Windows!

[lzhoucs]

I wonder if there's a way to tell if some feature documented in kll spec is implemented/unimplemented. I am playing key mappings based on kll spec, the following is not working:

U"DELETE"(H:1s) : U"0"; # 5.1.11 Timing

But I don't know if it is an user error or it is simply not implemented yet, until I see this ticket. So I wonder if there's some list of unimplemented features being maintained, so I can avoid trying to get something unimplemented to work in my mapping file.

[haata]

Right now the things that aren't implemented:

• State scheduling anything inside parentheses like this (H:1s), though there are a couple of exceptions. This is what I'm working on now.
• Isolated keypresses i: syntax, U"A" i: U"Q";, will happen shortly after state scheduling

I'm going to start with state scheduling triggers. Results will come after.

There is one exception currently for rotations: https://github.com/kiibohd/kll/blob/master/kll/layouts/kira/release.1.layer.2.kll#L33

Other than bug-fixes, state scheduling is my highest priority right now. It's just a complicated feature which is why it's taken so long.

[azrrik]

Does this still not work?

I just received a Kira and I would like to have space on tap and function layer 1 on hold for my space bar.

[haata]

I'm nearly ready to start getting beta testers for state scheduling. Hoping to have something this weekend.

[kll]

My Kira arrived today as well. I've got three different boards now with KLL so definitely let me know how I can help.

[dmgm]

Thats exciting, so this KLL snippet should work soon?

# Refer 5.1.2.1 State Scheduling
U"CAPSLOCK" : U"LCTRL";
U"CAPSLOCK"(UR) : U"Esc"; #Single Key Input
U"LShift" + U"RShift" : U"CAPSLOCK"; #In case you need CAPSLOCK

[azrrik]

Has any progress been made on this issue?

I'm nearly ready to start getting beta testers for state scheduling. Hoping to have something this weekend.

[alanzchen]

Any update?