Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Shift, Ctrl, Alt, Super, Alpha, Beta, Gamma, Delta layers #617

Open
mondalaci opened this issue Apr 30, 2018 · 36 comments

Comments

Projects
None yet
@mondalaci
Copy link
Member

commented Apr 30, 2018

  • Add modifier layers for Shift, Ctrl, Alt, and Super. This is a clearly popular feature based on #616, #592, and #248.
  • Add extra, optional layers named Alpha, Beta, Gamma, and Delta.

None of the above layers will be used in the default configuration, and they won't be visible by default. A plus sign will allow to add them on a per keymap basis.

@eltang

This comment has been minimized.

Copy link
Collaborator

commented Apr 30, 2018

I believe the most flexible way to implement this is to allow a key to trigger two actions (one to activate the modifier and one to switch the layer). However, it would require that keymaps be able to contain more layers than the current four.

@mondalaci

This comment has been minimized.

Copy link
Member Author

commented Apr 30, 2018

We're on the same page. The way to implement this is to make keymaps contain 4 more layers for the 4 modifiers. The firmware would switch to the relevant modifier layer if there's a key defined on that modifier layer which is not none action.

@mondalaci mondalaci changed the title Allow per-modifier scancodes Add Shift, Ctrl, Alt, Super, Alpha, Beta, Gamma, Delta layers May 1, 2018

@piratk

This comment has been minimized.

Copy link

commented May 7, 2018

If you intend to update the layers vs keymaps, perhaps make it possible to have the same layer in different keymaps.

@mondalaci

This comment has been minimized.

Copy link
Member Author

commented May 8, 2018

@piratk I'm not sure whether you mean the same layer with different content in different keymaps, or the same layer with the same content in different keymaps. The former will be implemented. I'm not comfortable with the latter because it'd make things more compicated for users, especially newcomers.

@piratk

This comment has been minimized.

Copy link

commented May 8, 2018

If I understand the terminology correct, a keymap is selected via the three character display, and then one of four layers is active; base, mouse, fn and mod.
It would be beneficial if, when creating a new keymap, that it was possible to share some of the layers from another keymap (for instance, the mouse layer may always be the same, but modified from the original one, because left and right mouse buttons are switched on the mouse layer), and when that layer is changed, it is changed on all keymaps.

@mondalaci

This comment has been minimized.

Copy link
Member Author

commented May 8, 2018

Now I clearly understand what you're after. I can see that this would be useful in some cases, but it'd make configuration more complex. I'd much rather stick to the current behavior. More work is involved in some cases when tweaking multiple keymaps but the concepts are simpler.

@mondalaci

This comment has been minimized.

Copy link
Member Author

commented Jun 18, 2018

Blocked by #562.

@TorC8

This comment has been minimized.

Copy link

commented Jul 13, 2018

Just found this. I think when editing keymaps, you might consider adding the ability to "copy layer from keymap", and be able to select any keymap, or really, any specific layer thereof to copy from. Still keep each keymap as a self-contained unit as far as agent is concerned. If you want to be fancy, also offer a "copy layer to" and be able to select which other keymaps should also use the currently shown layer.

@mondalaci

This comment has been minimized.

Copy link
Member Author

commented Jul 13, 2018

@TorC8 Can you elaborate on your exact use case that justifies this feature?

@TorC8

This comment has been minimized.

Copy link

commented Jul 13, 2018

As much as I would use it, I could just export to a human readable format and copy layers around as needed (or at least I figure that would be possible). Chances are, I'll have one or maybe two layouts I actually use and once I get them set I won't change them much, and only small tweaking that could be fairly easily kept in sync manually. It's more likely people who play around with their keymaps all the time who might find it useful.

@mondalaci

This comment has been minimized.

Copy link
Member Author

commented Jul 13, 2018

@TorC8 Thanks for explaining! We'll consider implementing it, but it'll hardly be part of this feature.

@mhantsch

This comment has been minimized.

Copy link

commented Jul 25, 2018

How would the additional layers work if I wanted a combination of layer-switching keys to trigger a particular layer? For example: Ctrl switches to Ctrl-Layer, Alt switches to Alt-Layer, and Ctrl+Alt held down together switches to Delta-Layer. How would I configure such a behaviour?

@mondalaci

This comment has been minimized.

Copy link
Member Author

commented Jul 25, 2018

It won't be possible to switch to a layer by pressing a combination of keys. You'll be able to map switch layer actions to keys featuring the extra layers to be added.

The current behavior is that the active layer stays active until its key is released. Think of holding the Mouse key, and the pressing Mod, which is accelerate on the Mouse layer. I stongly feel that this behavior is the right thing to do.

What I'm unsure about is the combination of modifier layers and non-modifier layers. Normally, modifiers compose with other keys, but having their own layer is a different story. I'd probably stick to the current behavior, and only allow the first layer pressed to be active until released.

@luteijn

This comment has been minimized.

Copy link

commented Jul 26, 2018

What exactly is the issue around not allowing to switch from say the Fn layer directly to Mod layer, but always having to go back to the Base layer first? My guess that it has to do with wanting to be able to just drop back to base layer always on release of a layer switching key, instead of keeping some sort of improved track of where one is and what keys are currently pressed, and on a wish to keep behavior consistent between 'hold to activate' and 'double tap to lock'?

If keymap switching is quick enough, people might be able to do some the things they want to do with layers with keymaps instead, but switching back to their base keymap would be an extra keystroke. One way to handle this might be to make it possible to tie actions to key press, hold and release separately...

Of course all exotic features...

@mhantsch

This comment has been minimized.

Copy link

commented Jul 26, 2018

@mondalaci I understand your argument for the sake of simplicity. What I was wondering is if you would allow the following to be configured:
On the base layer, Ctrl activates the Ctrl layer and Alt activates the Alt layer.
On the Ctrl layer, Alt is configured to activate the Delta layer.
On the Alt layer, Ctrl is configured to activate the Delta layer.
If you hold down one of the two keys, then also hold down the second, would an additional keystroke then be resolved through the Delta layer?

@mondalaci

This comment has been minimized.

Copy link
Member Author

commented Jul 26, 2018

@luteijn @mhantsch The reason for not allowing what you're after is to keep things simple.

People routinely write emails to us asking how to swap Fn and Alt in Agent, for example. The more complex Agent gets, the more people will have trouble with it. I consider simplicity a feature, and I respect your desires, but we have to draw the line in order to keep things simple.

On a related note, switch to a non-base layer in Agent, click on a key, then click on the Layer tab. You'll see the message "Layer switching is only possible from the base layer". This is by design, so that people are far less likely to mess things up.

@IzK666

This comment has been minimized.

Copy link

commented Jul 27, 2018

What about an "expert" or "advanced" checkbox (or both)?
I understand that agent should be as easy as possible to use for a regular users (and for beginners with UHK), but it cannot be only for these users.

@mhantsch

This comment has been minimized.

Copy link

commented Jul 27, 2018

@mondalaci Appreciate your clear decision, although I don't necessarily agree on your choice. As mentioned earlier, I coach agile teams, and you exhibit the best behaviour of a good Product Owner: saying "no" to some feature requests. (Seriously!)

Am I happy that I will not be getting my wanted feature? No, of course not. I believe that a gadget called Ultimate Hacking Keyboard should go all the way to satisfy that wants of experts and power users. That's what I associate with the word "ultimate".

@luteijn Are you ready to dive into custom firmware development (and custom agent development) for the UHK? ;-)

@luteijn

This comment has been minimized.

Copy link

commented Jul 27, 2018

@mhantsch not yet :) I can build the firmware and can manage some small changes in behaviour, but whenever I try something non-trivial, usually end up with breaking things as I have no complete understanding of all that's going on and probably am breaking timing of the basic communications. Anyway it is probably better to hold off messing with things until the official firmware stabilizes so it is worth studying it for reference. The Macro feature seems the most free-form configuration so might be easiest to extend to run features on the keyboard without messing up basic functionality.

Building agent fails for me, probably because running into issues with the version of node mentioned elsewhere, haven't really looked into it much as I don't really like the whole heavyweight GUI approach for my own use. Again, once the official Agent is stablized, it can hopefully serve as documentation to build a more traditional lightweight daemon with some CLI tools to e.g. set LEDs, remap keys/macro's and internal values on the fly replacement.

And of course one needs to have free time too, which is usually the limiting factor for me.

@mondalaci

This comment has been minimized.

Copy link
Member Author

commented Jul 27, 2018

"Ultimate" is up for definition. The best gaming keyboards are super intuitive to configure, and firmwares like Kaleidoscope or QMK offer the most customizability at the expense of having to delve deep into their APIs. Agent allows for easy and deep configuration which is a unique offering, but this involves (healthy) compromises.

Advanced options could work, although I can clearly see that your requests would introduce a ton of complexity and long term mainteance burden, and I doubt if they worth it.

I'm not against extending the feature set over time, but features should be evaluated very carefully, and we should do it one step at a time, because the underlying serialization format is very complex, easy to break, and hard to migrate.

In the first round, I'd like to get this implemented as simply as possible and possibly extend it later.

@piratk

This comment has been minimized.

Copy link

commented Jul 30, 2018

I think the comments in this thread is starting to sway off from topic. With that said, I would like to take this opportunity to say that once advanced features are available, layer switching on key-release would be interesting (not sure what to use it for but that is another question):

Say, pressing Fn, and then left Super keyboard goes into Delta layer, but then releasing Fn it could go into Alpha layer, where just pressing Left Super on base layer would just be Left Super.

@luteijn

This comment has been minimized.

Copy link

commented Jul 30, 2018

Let's see what comes out of this, but as I currently understand the proposal, pressing ctrl-then-alt would execute whatever is bound to alt on the ctrl layer, and pressing alt-then-ctrl would execute whatever is bound to the ctrl key on the alt layer. Now that's going to be confusing if they aren't bound to the same action.

@mhantsch

This comment has been minimized.

Copy link

commented Jul 30, 2018

@luteijn Yes, that is true, although Agent could be clever: Similar to those checkboxes that allow you to map a key on all layers or on all keymaps, it could offer to automatically map both (or all - maybe you want to use three or four modifiers together?) combinations of simultaneous presses to the same destination layer.

You'd go to the Ctrl layer and configure the layer switch on the Alt key, and there would be a message like "this layer will be activated using multiple modifiers" and a checkbox "[ ] automatically map all orders of combinations".

@mhantsch

This comment has been minimized.

Copy link

commented Aug 20, 2018

@mondalaci One more thought on the multi-mod switching: won't you need this to implement layers 5 and 6 of the Neo keymap (see #678)? (Although, I'll admit that these layers only contain seldom-used greek and mathematical symbols, so one could possibly get by without them.)

@mondalaci

This comment has been minimized.

Copy link
Member Author

commented Aug 20, 2018

@mhantsch You're right. Neo2 is pretty much the craziest layout which is the reason it'll be supported completely the last by the UHK, if ever.

@mhantsch

This comment has been minimized.

Copy link

commented Aug 20, 2018

@mondalaci OK, makes sense.

If you get the 8 layers described in this issue working (independently, no multi-mod layers!), I honestly believe you will already enable a lot of use cases. Including Neo layers 1-4.

@jceb

This comment has been minimized.

Copy link
Contributor

commented Oct 10, 2018

@mondalaci is there a timeline for the implementation of this feature? I'm mainly interested in just one functionality right now: make <Esc> (default key w/o modifiers), ~, and ` live on the same key and make Shift-<Esc> produce ~.

Maybe, if you could outline the tasks and give some hints, someone is able to help implement it.

@mondalaci

This comment has been minimized.

Copy link
Member Author

commented Oct 10, 2018

@jceb There is no ETA for any feature. This one is unusually hard to implement properly, and it's blocked by a major feature, so I rather wouldn't even try to outline it at this point. We'll get there eventually. Sorry, but it's the best I can offer now.

@SirVer

This comment has been minimized.

Copy link

commented Oct 13, 2018

@mondalaci I am also a heavy NEO user and have now a setup that is partially between software and partially implemented on the UHK. I'd love to fully support Neo on the UHK eventually. If that ever happens, I will buy two more and just always carry it with me :)

@mondalaci

This comment has been minimized.

Copy link
Member Author

commented Oct 13, 2018

@SirVer We better make this feature happen then. :)

@snaggen

This comment has been minimized.

Copy link

commented Nov 5, 2018

Stumbled upon this issue, searching for a solution to my config problem. I basically want to use US layout (since it is better than my native swedish for programing), but I need swedish characters. So my plan was to have the OS use a swedish keyboard. Then remap the keys to match the physical keys on the US layout on the UHK. Then add the swedish chars to the mod-layer.
However, with the current configuration it is impossible to change the key for the number two, from being the swedish 2 with a " char on shift, to be a 2 with a @ char on shift, since I can't remap just the shift action of the number keys.
So my current workaround for this is to use a english keymap, with macros that uses the compose key. However, that makes the keyboard linux dependent. So my wife will not be able to use it on her mac and windows computer. So I really hope to get a shift layer, since that would make my original remap possible, and get it plug and play and OS independent.

Edit: Even better workaround was to use the Swedish (US) keymap that seems to exist these days on Linux. This makes it work exactly as I want on linux, with the OS dependency as the only downside.

@onnimonni

This comment has been minimized.

Copy link

commented Nov 10, 2018

Hey! I have been a long time user of karabiner and its feature of space+homerow=1234567890.

Could we also add spacebar as a modifier to this feature list?

@mondalaci

This comment has been minimized.

Copy link
Member Author

commented Nov 10, 2018

@onnimonni Sorry, but this is not planned. You can set up space as a dual role key in Agent.

@onnimonni

This comment has been minimized.

Copy link

commented Nov 10, 2018

I see. That will do it as well 👍

@jwr

This comment has been minimized.

Copy link

commented Jan 3, 2019

I just wanted to throw in another use case: I'm using the UHK with many operating systems. I would like to ease the pain and, as an example, make Command-R in a Linux keymap send Control-R, to mimic the MacOS behavior (similarly for Command-T, and X/C/V for copy/paste). Macros get me half-way there, I need the additional layers to be able to map a macro to Command-R (Super-R).

I am also not far from redefining Ctrl-{AEFB} under Linux to map to cursor keys (home/end/left/right), as I find the lack of system-wide keybindings frustrating.

Such complex keymaps should be possible with the UHK.

@wesrt1

This comment has been minimized.

Copy link

commented Feb 18, 2019

Count me in as one for additional layer-switching from non-base layers or combinations of layer-switching keys.

As far as ease-of-use is concerned, it would require no changes to the Agent's interface aside from changing the notice about layer-switching and it wouldn't really introduce any confusion, as anyone who would want to use the feature would know what they were doing and anyone else just wouldn't use it. If you're going to add more layers, you'll need a good way to do it anyway, as there are only so many keys assignable to layer-switching. Combinations of layer-switching keys would work very well for this, and in my opinion would improve usability.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.