HyperSpace 👽 (🔹 on spacebar). Usage, issues and ideas.

[viviengarcia]

I have a rule converting my spacebar to a Hyperkey, so a… 🛸 HyperSpace 🛸. I use it to multitask, triggering OS-level shortcuts like mission control or background apps like Raycast. It's not for front apps.

HyperSpace is pretty useful because both its size and central positiion, making it easy to do all combinations one-handed. Another benefit is getting capslock back for other multi-modifiers combinations.

While it works well, it has issues:

• Accidental overlap. When I type fast I often mis-press other keys before releasing the spacebar. This quick overlap either triggers a shortcut or outputs nothing instead of the 2 expected space + character. "basic.to_if_held_down_threshold_milliseconds":75 mitigates the issue, but I still have hiccups sometimes, because this parameter doesn't really measure the overlap interval.
• No long-press and repeat. Repeating a character or using some features require the spacebar to be long-pressed, but I set basic.to_if_alone_timeout_milliseconds to 200ms to fire shortcuts in quick succession so long-press is disbaled. So I blacklisted games (don't need multitasking then), and I modified shift + spacebar to send a conventional, repeatable signal.

Now I'd like to better differentiate shortcut keystroke from text typing.

• If spacebar is pressed no longer than 180-200ms AND another key is pressed before it's released:
  • if overlap is bigger than, say, 70 milliseconds AND is released just before/at the same time/after the additional key -> send shortcut
  • else -> send space character

Technically, the from.simultaneous options seems perfect for that, but the simultaneous definition doesn't seem geared towards modifier + key combinations?

I'm not sure about that, any confirmation would be greatly appreciated.

Also, it would be nice if we could choose between AND and OR when using bundle_identifiers along file_paths, just saying…

Any thought? Here is my current rule, in any case.

{
    "description": "HYPER SPACE \n ␣ + ? → ◆",
    "manipulators": [
        {
            "conditions": [
                {
                    "bundle_identifiers": [
                        "^uk\\.co\\.hellogames\\.nms$"
                    ],
                    "type": "frontmost_application_unless"
                }
            ],
            "from": {
                "key_code": "spacebar",
                "modifiers": { "mandatory": ["left_shift"] }
            },
            "to": [{ "key_code": "spacebar" }],
            "type": "basic"
        },
        {
            "conditions": [
                {
                    "bundle_identifiers": [
                        "^uk\\.co\\.hellogames\\.nms$"
                    ],
                    "type": "frontmost_application_unless"
                }
            ],
            "from": { "key_code": "spacebar" },
            "parameters": {
                "basic.to_if_alone_timeout_milliseconds": 200,
                "basic.to_if_held_down_threshold_milliseconds": 75
            },
            "to_if_alone": [{ "key_code": "spacebar" }],
            "to_if_held_down": [
                {
                    "key_code": "left_shift",
                    "lazy": true,
                    "modifiers": ["left_command", "left_control", "left_option"]
                }
            ],
            "type": "basic"
        }
    ]
}

[gforien]

What you're trying to define is a virtual modifier
You don't need to_if_held_down or simultaneous for this

See https://karabiner-elements.pqrs.org/docs/json/extra/virtual-modifier/

    {
        "type": "basic",
        "from": {  "key_code": "spacebar" },
        "to": [ {  "set_variable": {  "name": "hyperspace",  "value": 1  } }  ],
        "to_after_key_up": [ {  "set_variable": {  "name": "hyperspace",  "value": 0  } }  ],
        "to_if_alone": {  "key_code": "spacebar" },
    },
    {
        "type": "basic",
        "from": {  "key_code": "a" },
        "to": {  "key_code": "x", "modifiers": ["left_command", "left_control", "left_option"]},
        "conditions": [ {  "variable_if": {  "name": "hyperspace",  "value": 1  } }  ],
    },

(the to_if_alone is not included in the documentation, but in most cases you want it)

I see a lot of bundle identifiers if your config. In most cases you can just use file_paths : [ "No Man's Sky" ] instead of having to look up bundle identifier

bundle_identifiers and file_paths receive an array of regexes, evaluated with OR by default. You cannot have two frontmost application at the same time, so I don't think it would make sense to have a condition on "application 1 AND application 2".

[viviengarcia]

Thanks for the kind reply. I completely missed this feature and it's nice to find another tool.

Unfortunately, your solution doesn't really answer my needs:

1. with virtual-modifiers I would have to specify EACH shortcut I'd use my hyperkey with,
2. it has the same issue : unwantedly triggering the hyperkey when I type fast. I hoped there was a mean to mitigate that.

About bundle_identifiers and file_paths, this is whant I meant.

This will trigger if EITHER No man's sky OR Affinity designer are front:

{
    "bundle_identifiers": [
        "^uk\\.co\\.hellogames\\.nms$",
        "^com\\.affinity\\.afdesigner$"
    ],
    "type": "frontmost_application_if"
}

But with the condition below, BOTH apps would have to be front SIMULTANEOUSLY (which is impossible) to trigger the rule, because you can't have bundle_identifier OR file_paths, it must be bundle_identifier AND file_paths (which is illogical, they both target the same kind of conditions):

{
    "bundle_identifiers": [
        "^uk\\.co\\.hellogames\\.nms$"
    ],
    "file_paths": [
        "^com\\.affinity\\.afdesigner$"
    ],
    "type": "frontmost_application_if"
}

Anyway, I should probably use path_files for everything, since emulated apps don't have bundle identifiers…

Edited for clarity.

[gforien]

Looks nice, I didn't know about multiple front apps at the same time ! Is it only 2 apps, or can you have 3 or more frontmost application ?

Which karabiner version are you using btw ?

I understand that my answer doesn't meet your needs. I shared it because I've been in your situation and this is how I solved it, but I understand that it may not fit everyone.

I also encountered pain points 1) and 2) that you describe. This is how I solved them

1. specifying each keymap is not difficult
   I guess that your pain point is writing all this configuration in JSON by hand ?

Lots of people use an External JSON generator to generate JSON rules instead of writing them by hand. It offers several advantages like using variables, conditions, and splitting your config across several files. But also, it makes it easy to "define each keymap" (that is, define a virtual layer). Users typically define several virtual layers in their config.

For instance, I currently have 480 karabiner rules (spread across 4 profiles, so each profile does not contain that much), but each rules only takes up a few lines like this

      - <<:   *if_terminal
        from: {key_code: d, modifiers: {mandatory: left_command}}
        to:   {key_code: d, modifiers: left_option}

      - <<:   *if_terminal
        from: {key_code: h, modifiers: {mandatory: left_command}}
        to:   {key_code: h, modifiers: left_option}

      - <<:   *if_terminal
        from: {key_code: j, modifiers: {mandatory: left_command}}
        to:   {key_code: j, modifiers: left_option}

      - <<:   *if_terminal
        from: {key_code: k, modifiers: {mandatory: left_command}}
        to:   {key_code: k, modifiers: left_option}

      - <<:   *if_terminal
        from: {key_code: l, modifiers: {mandatory: left_command}}
        to:   {key_code: l, modifiers: left_option}

      - <<:   *if_terminal
        from: {key_code: m, modifiers: {mandatory: left_command}}
        to:   {key_code: m, modifiers: left_option}

EDIT: (ofc the rules are reused. I have 480 generated rules, but my config files do not contain that much)

2. I don't use spacebar as my leader (hyper) key. I do remap space within specific apps, and I remap +space, though. But for me, leader key does not collision at all with normal usage. It was the easiest solution that met my needs.

That being said, I’m sure it’s possible to use Space as a leader key if you either

a) define your keybindings accordingly, or

b) prevent accidental overlap. If you’re familiar with how keyboards work —eg polling rate and debounce time— you’ll know that when two keys are pressed almost simultaneously, there’s no guarantee that they will register without overlap. If I needed that guarantee, I’d opt for a mechanical keyboard with documented specs and adjust the debounce delay at the driver level.

[viviengarcia]

At the time of my previous comment, I was using Karabiner 15.0.X Now I'm using 15.2.0

There can't be more than one front application at the same time. My comment wasn't clear enough, I edited it.

1. specifying each keymap is not difficult. 

It's not, but why would I use virtual modifiers that have the same issues with overlaping, rather than specify one rule ONCE and be done with it? It's like having a whitelist feature and not using it in favor of a never-ending blacklist…

For now, as previously mentioned, my rule works. I use spacebar as my hyperkey, it's just that it trigger by accident sometimes when I type too fast. It's not a keyboard issue, it's a PEBCAK issue. But it could be entirely mitigated by having a condition targeting the overlap duration, something like "accidental_overlap_duration" : 75 (in milliseconds), which would resolve like this:

if "accidental_overlap_duration" ≥ 76 {
    cmd + alt + ctrl + shift
} else {
    spacebar
}

This would prevent most of the accidental triggers I have for now.

I have to say I like the way you format your rules. Looks like it's done using this generator?
I don't want to learn a new tool just for that, but it's nice to know the tool exists. Makes me regret even more that Karabiner uses JSON in the first place (I understand JSON is perfect for most people, but I don't like it. It's hard to read and harder to write. Why so verbose? Although I'm only a beginner, Python is the way IMO).

Anyway, I'm going to rise a feature request about targeting overlap duration, perhaps the author will find it relevant?

[gforien]

There can't be more than one front application at the same time.

Ok, so back to what I said in my first comment then.

But with the condition below, BOTH apps would have to be front SIMULTANEOUSLY

No actually conditions bundle_identifiers and file_paths are evaluated with logical OR
Testing with Karabiner 14.12.0 here, this rule binds 1 to 2 in both applications

      - type: basic
        from: {key_code: "1"}
        to:   {key_code: "2"}
        conditions:
          - type: frontmost_application_if
            bundle_identifiers: [nightly]
            file_paths: ["Zen Browser"]

It's not, but why would I use ...

I did not suggest that you should do the same.
I'm only sharing how I solved these pain points, but to each his own 👍

Have a nice day mate

Looks like it's done using this generator?

It's not CompMode, I use my own generator

[viviengarcia]

No actually conditions bundle_identifiers and file_paths are evaluated with logical OR Testing with Karabiner 14.12.0 here, this rule binds 1 to 2 in both applications

You're right! I was convinced it was an AND because I thought I tested it but apprently my memory was wrong. Perhaps it's with when you test against 2 conditions like app & device… Anyway it's pretty cool it works like that, soon after reading your comment I had to use it and it works pretty good. Thanks!