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

Open
mondalaci opened this issue Apr 30, 2018 · 65 comments · May be fixed by #1548
Open

Add more layers #617

mondalaci opened this issue Apr 30, 2018 · 65 comments · May be fixed by #1548

Comments

@mondalaci
Copy link
Member

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

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

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

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

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

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

@mondalaci mondalaci commented Jun 18, 2018

Blocked by #562.

@TorC8
Copy link

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

@mondalaci mondalaci commented Jul 13, 2018

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

@TorC8
Copy link

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

@mondalaci mondalaci commented Jul 13, 2018

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

@mhantsch
Copy link

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

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

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

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

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

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

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

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

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

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

@Myridium
Copy link

@Myridium Myridium commented Oct 5, 2019

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

@mondalaci mondalaci commented Oct 5, 2019

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

@debbiev debbiev commented Jan 23, 2020

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

@mondalaci mondalaci commented Jan 23, 2020

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

@debbiev debbiev commented Jan 23, 2020

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

@UndeadKernel UndeadKernel commented Jan 23, 2020

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

@kareltucek kareltucek commented Jan 24, 2020

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

@opensensesolutions opensensesolutions commented Jan 25, 2020

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 ( #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.

@mondalaci mondalaci changed the title Add Shift, Ctrl, Alt, Super, Alpha, Beta, Gamma, Delta layers Add more layers Jan 27, 2020
@peterquiel
Copy link

@peterquiel peterquiel commented Mar 12, 2020

Having Shift modeled as a separate layer would solve my problem of using Colemak Layout on system with german layout.

@opensensesolutions
Copy link

@opensensesolutions opensensesolutions commented Mar 12, 2020

@peterquiel Can you do that now with the Mouse layer and assigning the Mouse layer to the shift key? Obviously more layers helps if you're already using the mouse layer for other things.

@mhantsch
Copy link

@mhantsch mhantsch commented Mar 26, 2020

@debbiev @opensensesolutions I have found that I can solve a number of use cases around the need for multiple layers by using different keymaps. For example, @opensensesolutions suggested different setups for different customers -- maybe one keymap per customer? @debbiev talked about a mirrored layer for one-handed typing, and a programming layer -- maybe separate keymaps for theses cases?

What I did is define one key combination (Fn-/ in my case) which rotates through keymaps, i.e. on each keymap it is mapped to switch to the next keymap in my sequence. I just press that button multiple times until the keymap I want shows up on the 14-segment display. I use it, for example, to switch to a "number pad" where 7-8-9 / U-I-O / J-K-L / M-,-. form a number pad for easy number entry. I switch keymap, then enter my numbers, then switch back to my normal keymap.

Hope this is helpful for some of you.

@peterquiel
Copy link

@peterquiel peterquiel commented Mar 26, 2020

@opensensesolutions well, I already use every layer.

@mhantsch Interesting idea, but I use different keymaps to be able to use same "keybord" behavior on different systems.
I'm typing on colmak layout and not every system provides that keyboard layout. Furthermore, I want to be able to type german umlauts like ß, ü and the swedish å.
It's possible, if the system provids colmak layout. If not, I have to use a layout on the system, that provides these special characters and create a keymap to that maps the colmak shortcut like Alt Gr+s for ß or Alt Gr+w for å to the appropriate key for the layout.

And since all of these layouts move around al the other symbols, .. it's very complicated to create two keymaps for every layout in order to expand the number of layers.

Would be great to have as many layers as you want.

@barnc
Copy link

@barnc barnc commented Jul 9, 2020

Just chiming in my support on this one - with the upcoming key cluster module additional layers would go a long way towards making the most use of it!

@ert78gb ert78gb added this to To be done in Agent issues Oct 8, 2020
@bitalchemist
Copy link

@bitalchemist bitalchemist commented Jan 25, 2021

UI wise the way I'd see it eg if Shift was held at Mod layer - it'd be equivalent of brand new layer (Seperate from Mod). Imho it's a necessary feature, quite disappointed with my purchase because it's not implemented.

@mondalaci
Copy link
Member Author

@mondalaci mondalaci commented Jan 25, 2021

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

@eetnar
Copy link

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

@mhantsch mhantsch commented Mar 22, 2021

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

@kareltucek kareltucek commented Mar 22, 2021

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

@MichaelRBond
Copy link

@MichaelRBond MichaelRBond commented Jun 16, 2021

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

@miromannino miromannino commented Jun 26, 2021

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

@mondalaci mondalaci commented Jun 26, 2021

@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

@miromannino miromannino commented Jun 26, 2021

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

@mondalaci mondalaci commented Jun 27, 2021

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Agent issues
  
To be done
Linked pull requests

Successfully merging a pull request may close this issue.