Add more layers

[mondalaci]

Currently, the Base, Mod, Mouse, and Fn layers are available. We'll extend these layers with 4 regular layers (Fn2, Fn3, Fn4, Fn5) and 4 modifier layers (Shift, Ctrl, Alt, Super).

All of these layers will be optional (can be added or removed per keymap) with the exception of the base layer which cannot be removed.

See the updated layer button group in which the order of Mouse and Fn is exchanged compared to the current order, and there's a dropdown arrow at the end:

The dropdown contains a checkbox for every optional layer:

The implementation of the above dropdown is not consistent with the Bootstrap 3 style as it's only meant to be a demonstration. The dropdown must not disappear upon clicking a checkbox. Unchecking a checkbox must be confirmed by a confirmation popover containing: Do you really want to delete this layer?

Modifier layer names must be OS-specific. So for example, Alt becomes Cmd on Mac.

The layer button group must update immediately upon toggling the layer checkboxes, and the button order must be the same as the dropdown item order.

The user configuration format will change. Right now, a keymap contains a fixed number of 4 layers. According to the above, a keymap will contain at least 1 and at most 12 layers. A layer id must be included into each layer object.

[eltang]

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]

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.

[piratk]

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

[mondalaci]

@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]

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]

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]

Blocked by #562.

[TorC8]

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]

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

[TorC8]

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]

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

[mhantsch]

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]

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]

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]

@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]

@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]

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]

@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]

@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]

"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]

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]

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]

@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]

@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 https://github.com/UltimateHackingKeyboard/agent/issues/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]

@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]

@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]

@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]

@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]

@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]

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

[snaggen]

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]

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]

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

[onnimonni]

I see. That will do it as well 👍

[jwr]

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.

[yaxunema95]

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.

[ghost]

Hm, I feel like it'd be a good idea to make sublayers (or combo layers): in agent, if I've chosen "Mod" layer, I'd see as a second row of sub-layers, by default there would be "base" - which represents situation when no extra modifier key is being held.

Then, I'd like to be able to add custom sublayer, by selecting or pressing the key. And, once I've selected the key, eg "ctrl", under that sublayer initially I'd see clone of base layer, ready to be modified. Changes in this layer will be accessible by holding "Mod" + "Ctrl".

Use case: I've been trying to find a way, so clicking "Mod + Shift + J" would be equal to "Ctrl + Shift + ArrowLeft", so when I'm selecting text it'd select in words, rather than symbols. (currently I'd have to hold "Mod + Shift + Ctrl + J", which is a bit bdsm).

[mondalaci]

@bruddah The suggested feature is not planned, but feel free to check out https://github.com/kareltucek/firmware which provides advanced configuration options.

[TorC8]

@bruddah For your specific usecase listed, how about remapping the shift key on the Mod layer to Ctrl + Shift?

[ghost]

@TorC8 it'd break other combos, eg selection till the end/start of line. Thanks @mondalaci I'll try it out.

[UndeadKernel]

Hi @mondalaci. Is there any progress/plans regarding those alternative layers?

[mondalaci]

@UndeadKernel Not yet. Related news will be posted here.

[Myridium]

I'm rather disappointed that this feature hasn't been implemented. I expected it before purchasing.

Anyone who uses an alternative keyboard layout to QWERTY will know the pain of Ctrl+X, Ctrl+C and Ctrl+V bindings being different. A lot of the default Ctr-F commands etc have been chosen at least partly based on where those keys are physically located on the QWERTY layout, making them easily accessible. It also seems that programs differ in whether they want to read the scancode or the character of the sent key, causing some additional headaches.

A swathe of shortcut key issues for alternative layout users (including having to manually rebind shortcuts for damn near every program you use) can be alleviated by changing the layout to QWERTY while a modifier key is pressed. I really don't understand why this (#617) hasn't been implemented because it seems like such an elegant solution, in hardware, for a pervasive problem, and many people have already thought about it. Have the creators of the UHK not experienced such issues themselves?

[mondalaci]

@Myridium This is way more complicated than you might imagine as it's blocked by multiple major issues, and we have to dedicate a lot of resources to the modules nowadays. In time meantime, feel free to give a try to Karel's firmware.

[debbiev]

Ergodox's tool (Oryx) allows you to create up to 32 layers. Name them whatever you want. then you just decide which key(s) to press to activate any layer. Why not do it like they do?

https://ergodox-ez.com/pages/oryx,

I have one, and it's super easy. I just don't like the ortho-linear hardware layout.

[mondalaci]

The main reason is that 32 layers are a tad overkill. Very few people need 4+ layers, and practically nobody needs 8+ layers.

The second reason is that I want to keep things simple. Agent is easier to use than Oryx, and I'd like to keep it that way.

[debbiev]

Agreed. I'd be really happy with 6 layers: the existing 4. plus 5: mirrored qwerty for one-handed typing 6: for programming, put the number/special character top row down on the home row, so I can easily hit them without looking at my fingers. Plus that would leave lots of unused keys for other stuff.

I'd be really happy with 6 layers. 4 is not quite enough.

[UndeadKernel]

I would also second (and very much welcome) the addition of two more layers. There are so many interesting things you can do when you have more layers available to you. The examples of @debbiev are such cases. I would use the extra layers to emulate emacs and vi bindings that apply on any application. For example, different vi states could be activated with the press of a button (activating one layer for each vi state).

[kareltucek]

@debbiev @UndeadKernel if you are tired of waiting and don't mind getting your hands dirty, please feel free to check out https://github.com/kareltucek/firmware in the meantime.

Among other things, It allows you to use more than 4 layers by using layers of different keymaps (search for holdKeymapLayer). I even experimented with both mirrored keymap and vi/vim bindings - the config can be found in the example section, however it is quite complicated and can potentially cause trouble if you don't know what exactly the thing does. Mimicking vi/vim is pretty complicated, because behaviour often depends on the context, and therefore various heuristics and additional stateful information have to be employed.

[opensensesolutions]

First off I have to say that I have been really impressed with the UHK hardware and software, it is a very well designed product and I'm very happy I got one. I am patiently awaiting my modules and appreciate that that takes precedence to new features. I just wanted to add my use case and a few thoughts I had on more layers, I apologize in advance for rambling, but in short:

• I'd be content with 4 more layers ( although 32 would be ULTIMATE :)
• with more layers you need more ways to get to those layers like alt-fn for layer beta
• macros should be able to switch keymaps (and maybe even layers)

Before I ordered I was hesitant due to the UHK essentially only having two programmable layers - fn and mouse ( base and mod are mostly tied up in essential keyboard features ). I have about 40 distinct computers and customers I deal with on a regular basis and software macro and password solutions are not always an option. Before the UHK I had some xkeys and a Mistel Barocco MD600 with essentially 4 keymaps and 2 layers, and it only lets you create 24 macros per keymap ( and that limitation isn't documented anywhere! ).

I have most of my keys labeled on the front of the keycap with a customer/computer name, and fn+key does one thing like enter a password and mouse+key does another, but to keep things consistent and add more functions more layers would really help. However there needs to be a way to access the additional layers, I'm out of keys as it is and using the microswitches on the bottom already ( which are too hard to press - I'd definitely ditch them in a TKL version ). I think the easiest solution is allowing modified keys to switch layers, for example shift-fn activates layer beta.

To get around the current layer limitation I've thought about creating a different keymap for each user since there doesn't seem to be a limit to how many keymaps you can have. But without being able to switch keymaps as part of a macro or automatically switching keymaps based on which virtual desktop I'm on it would be cumbersome to keep switching keymaps, which is where adaptive mode would help ( https://github.com/UltimateHackingKeyboard/agent/issues/555 )

The ability to switch keymaps (and maybe even layers) in macros would open up a lot of possibilities. Lets say I program fn-a to run a program that switches to my "a" customer virtual desktop, and switches the UHK keymap to the "a" customer keymap. Then mouse-p could type the password for my user, mouse-r could do the root password, mouse-r runs a common command, etc. and you could have many easily remembered commands per customer without crazy key labeling schemes. The same scheme could be applied in the more common use case of per-application macros.

I understand wanting to keep the product simple, but maybe the problem is the name - if you want to be the ULTIMATE hacking keyboard people expect every feature of every other advanced keyboard. But as long as its all open source we have the option to stop complaining and start coding - Thank you very much kareltucek for your work, I'll give it a try when I have some time.