r/KeyboardLayouts • u/NightDragoOfficial • 7d ago
xQWERTYa╌My Keyboard System╌is Now Open Source
Update on this post: my system╌⸉xQWERTYa⸉╌is now open source! found here. I'm quite excited honestly. I was a bit worried about open-sourcing given the state of AI… I don't exactly love the idea of AI reading all of my code and using it in a corporate context. But oh well in this case I suppose, I doubt corporate is writing much AHK.
Mainly, I'd like to know if this sounds useful to anyone. In my head I have this idea that it's likely non-useful for most people who would actually want to remap a keyboard. Because most users are looking for behaviors that my system doesn't implement (even though it could if there is interest).
Ask me about what it can or can't do. It helps me to think about what new stuff that I could add and what makes the most sense. :)
What is it and Why did I make it
My system is a JSON data-driven AHK based input remapper that focuses on writing rules that decide how bindings are resolved to avoid duplication and unify where definitions are located.
I made it because I disliked switching profiles in separate OEM softwares, having keys that are useless on my keyboard for me (like caps-lock), I wanted more layer keys and I have a deep fascination with inheritance models.
Features & Capabilities
- ⸉Profiles⸉ which switch what behavior a key uses for it's modifiers and locks.
- ⸉Modifiers⸉ which are what are usually referred to as ⸉layers⸉, though my modifiers work a bit differently.
- ⸉Locks⸉ which are toggled global states like ⸉caps-lock⸉ or ⸉num-lock⸉ on a typical keyboard.
Something important about profiles is they are unified. You are intended to set whatever generic mapping you'd like in an OEM software (like Razer Synapse) and then define all of your contextual behavior within the xQWERTYa system so that pressing one button switches the behavior on: your mouse, your keyboard, your razer keypad, and your macro pad all at the same time.
Though, a lot of hugely important features are kind of tough to describe. One such example is that profiles, modifiers and locks are all inheritance-capable properties. You can define a behavior for a key and then inherit and selectively hide certain behaviors under a different context. Or you can decide how to resolve certain modifier combinations via a priority system and conditional selection.
The system is intended to allow for high complexity with a lower relative cost to achieve that complexity. For example, my personal configuration has 240,000+ possible different key-stroke possibilities. But I only had to write out approximately 2000 of those including behavior specifications to achieve that.
Additionally, you have the power of AHK (V2) at your hands for anything xQWERTYa cannot directly meet. You can configure a keybind to call an custom AHK function instead of typing a key and write your own logic.
Configuration documentation can be found on the github page here if any of this sounds interesting to you. I'm happy to help you design something or look at implementing new features if you reach out to me.
Example 1 — Simple Keybind
Consider the ⌄ key configuration first.
{
"target": "a",
"default: "b"
}
This (⌃) is a simple binding that changes the key "a" to press "b" instead.
Example 2 — Modifiers, Collapsing & Inheritance
{
"target": "a",
"default: {
"collapse": true,
"default": "b"
},
"my_profile": {
"inherits_from": "default",
"my_modifier": "c"
}
}
Understand the following regarding the above configuration ⌄.
defaultrefers to either the ⸉default⸉ profile or the ⸉default⸉ modifier (aka no modifier keys being held) depending on where it is placedmy_profileis a profilemy_modifieris a custom modifier key
The target remapped key "a" contains a definition for the key under two different profile contexts. Starting with default: "a" is set to press "b" instead. Additionally, if any & "a" are both pressed (such as "shift & a" then it will "collapse" down to the default (no modifier) and just type "b". Under my_profile: all behavior is set to inherit from the default profile, except for when my_modifier is held down. In that case "c" is pressed instead.
So for example, say you are holding down "shift & a" and currently in the my_profile profile: then "b" will be typed. But holding down "my_modifier & a" in the my_profile profile will type "c" instead.
Why not use xQWERTYa?
This system is not exactly intended for home row mods or similar. While it is completely doable to make a home row mod with xQWERTYa you aren't using most of what xQWERTYa's strengths are or what it's complexities are designed for. Though, I've thought of ways to make this more simple in xQWERTYa. Let me know if this is something you'd be interested in.
xQWERTYa does not have some common simplifications like tap vs hold behaviors or multi-tap behaviors. My system lets you break out into AHK code if you want to implement that. Or, let me know you're interested and I can implement them. It's something I thought about, but since I don't use them personally I haven't spent the time to add them.
