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 more layers #617

Closed
mondalaci opened this issue Apr 30, 2018 · 78 comments · Fixed by #1548
Closed

Add more layers #617

mondalaci opened this issue Apr 30, 2018 · 78 comments · Fixed by #1548

Comments

@mondalaci
Copy link
Member

mondalaci commented Apr 30, 2018

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:

image

The dropdown contains a checkbox for every optional layer:

image

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
Copy link
Contributor

eltang 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
Copy link
Member Author

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
Copy link

piratk 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
Copy link
Member Author

@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
Copy link

piratk 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
Copy link
Member Author

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
Copy link
Member Author

Blocked by #562.

@TorC8
Copy link

TorC8 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
Copy link
Member Author

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

@TorC8
Copy link

TorC8 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
Copy link
Member Author

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

@mhantsch
Copy link

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
Copy link
Member Author

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
Copy link

luteijn 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
Copy link

@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
Copy link
Member Author

@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
Copy link

IzK666 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
Copy link

@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
Copy link

luteijn 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
Copy link
Member Author

"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
Copy link

piratk 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.

@mondalaci
Copy link
Member Author

I'm sorry you're disappointed. Chances are you can implement this using Karel's UHK firmware fork.

@eetnar
Copy link

eetnar commented Mar 7, 2021

I'd like to first say thank you for making the UHK :), I think the product is pretty cool.

With that out of the way, you can add me to the list of those in favor of adding more layers.

While it might seem like most people don't use a lot of layers, I'd argue that those who might consider non-standard keyboard sizes (60% or less) and thumb cluster boards (ergodox, uhk, dygma, ...) would be prime candidates for such functionality. Also in that group would be users who are heavy into macros and shortcuts.

My immediate use case would be in conjunction with tools like BetterTouchTool which I use to create a set of shortcuts for assorted activities. With additional layers, I could then group each category of shortcuts into their own layer.

For example, I'd definitely love to have a layer where I can put in all my window management shortcuts. It would make things more efficient for me to be able to move a window to the 4th quadrant of the screen by pressing a thumb button in conjunction with one of the letters on home row, as opposed to doing my normal finger acrobatics.

Since the home row is prime real estate, sometimes shortcuts end up in non-optimal spots. Additional layers could help in my efforts to keep frequently used shortcuts at or near the home row in general.

Other layer ideas that I might pursue, should additional layers be available, would include a numpad layer and a macros layer.

@mhantsch
Copy link

I think with the upcoming key cluster module, those additional keys are perfect for use as thumb keys for additional layers. At least I would want to use them for this. A prime reason for this feature request.

@kareltucek
Copy link
Contributor

And also a prime reason for UHK team not having time for it...

@MichaelRBond
Copy link

I'd also love to see another layer or 2.

As a work around right now I'm using the Keymaps to add additional layers. Mac keymap is my primary keymap and all my primary layers. PC keymap and its layers are for application specific mappings. This works well for applications where I don't have to do a lot of typing (like Games, GIMP, etc ...) but becomes less ideal for something like VSCode where i'm doing a lot of typing and would like to have a "VSCode" layer.

Right now my mouse layer has been remapped as a "vscode" layer. But, i lose all the mouse functionality doing that.

I wouldn't want to go crazy with 32 extra layers. But, 1 more would be nice.

I think 1 more layer + using the keymap work around would provide the right combination of available layers.

@miromannino
Copy link

Same here... I'd love to see this implemented. Definitely the thumb keys would be the perfect fit for this type of things. I do all day HCI and honestly "too complicated" just means there is a bit to work in the UI, but not impossible.

For example in UI why not having a simple + button that allows to add and name a new layer?

Screen Shot 2021-06-26 at 9 52 46 PM

Beginners will play with only these 4 layers, and for whoever wants they can have more. Enabling this feature might be even in the settings, and disabled by default if you are really concerned about it.

@mondalaci
Copy link
Member Author

@miromannino I think the original specification is more straightforward as modifier layers are functionally different from non-modifier layers, and adding a name introduces additional complexity.

@miromannino
Copy link

Yes if there is the limitation in the firmware that only few keys can do that then I agree. But, for example I have the | and \ key repeated (one above the enter and one next to the shift). I'd love to use one of these to activate a layer, similarly to how is possible with the ergodox where any key can do anything, including activation of an arbitrary level

@mondalaci
Copy link
Member Author

@miromannino I'm unsure what you are trying to achieve exactly, but chances are fair it's possible with Karel's UHK firmware fork.

@0x7FFFFFFFFFFFFFFF
Copy link

This is implemented? Cool! When will we get a new version?

@mondalaci
Copy link
Member Author

Yes, it is. We don't have an ETA. The next release is gonna be huge, and there are still some tasks to be done.

@alevani
Copy link

alevani commented May 19, 2022

@mondalaci do you eventually have an ETA on a possible update now? 😃

@mondalaci
Copy link
Member Author

Probably in two weeks.

@f0086
Copy link

f0086 commented Jun 20, 2022

That's awesome news! I hope I do no need to wait as long as I have waited for my UHK to receive :)

@okuuva
Copy link

okuuva commented Aug 31, 2022

Couldn't find any progress tracker anywhere about the next big release. Is there one somewhere? Been waiting this feature quite a while now.

@mondalaci
Copy link
Member Author

UltimateHackingKeyboard/firmware#505

@alevani
Copy link

alevani commented Sep 12, 2022

@mondalaci with the firmware now updated to version 9.0.1, the tracker UltimateHackingKeyboard/firmware#505 is outdated. Do we have a progress tracker for the agent alone regarding the upcoming update?

@mondalaci
Copy link
Member Author

@alevani We plan to release a new Agent version in September.

@mhantsch
Copy link

@alevani We plan to release a new Agent version in September.

Just updated to Firmware 9.1.0, but still not sure how to activate and use additional layers more easily.

@mondalaci
Copy link
Member Author

The new Agent version will enable the additional layers. We're behind schedule, but working on it.

@0x7FFFFFFFFFFFFFFF
Copy link

The new Agent version will enable the additional layers. We're behind schedule, but working on it.

Is it possible to release in 2022?

@mondalaci
Copy link
Member Author

Yes, we're working on it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Agent todo
  
Done
Development

Successfully merging a pull request may close this issue.