I am on a MOD layer and use Alt-Tab assigned to one key to enter the Alt-Tab overview. While still helding the MOD layer key (space key) I want to trigger arrows and other commands on the same MOD layer. But when I still keep the mod-key held those arrow-keys do not trigger, but instead they act like I would release the key-combo for Alt-Tab and therefore the highlighted window gets the focus instead of the arrow navigating in the tab-overview.
Alt-Tab is not a macro, but just Alt-Tab as a direct key defined. I also tried various macro versions, but could not get that working.
Is that possible? I also have Ctrl-w on the mod layer and would like to close the programs by pressing the relevant key on the mod-layer. That works with Kanata and I would like to have the same functionality with the UHK.
This is my MOD layer (Space-key held triggers MOD). The UHK has more keys, but I have the same 4x6 matrix on the UHK, although it looks a tad different due the row stagger.
The relevant keymap is âENDe - US Int. - no Katanaâ.
Is my question clear? I want to be able to use the complete MOD-layer, while the Alt-Tab overview is still visible (space-key still held). This allows me to interact with the tabs, very handy if I have many windows are open. That is such a convenient way to close programs or navigate to the wanted window.
Definitely possible, but probably not straightforward.
For instance you may use the alt as a sticky key with sticky-alt+arrows. Since your mod layer arrows are non-alted, this would require them to be remapped to alt+arrows temporarily. That can be done with overlayLayer for instance - bind alt+arrows into yet another layer (/keymap), and and replace your alt-tab key with:
overlayLayer mod ARR mod
holdKey sLA-tab
But then you also have to restore that layer when this is no longer needed, which means altering your mod layer macro:
// tap: space, hold: mod (Max approach)
set secondaryRole.advanced.timeout 200
// set secondaryRole.advanced.timeoutAction secondary
// set secondaryRole.advanced.triggerByRelease true
ifSecondary advancedStrategy goTo secondaryaction
primaryaction: final tapKey space
secondaryaction: final {
holdLayer mod
replaceLayer mod current mod
}
Thanks Karel, I am not sure if I understand your suggestion correctly.
I would need to create a modified navigation/ mod layer (with held-space) where all keys would need to be ALT-ed versions? Or just change the Alt-Tab definition to the new macro?
P.S.: I am famous to run into edge cases. I seem to have a tendency to not use programs in the standard way and/ or want or need special featuresâŚ.
If you have not tried that approach of being able to navigate in the Alt-Tab state ⌠that is really cool, once you start using it you do not want to miss it!
You refer to the attached config from your previous response? That shows me an empty base layer except for non-macro arrow key assignments. Then there is a mod-layer with the same. I do not see or understand how that relates to your âoverlayLayerâ you mention. Either the config is not what it is supposed to be or I do not get it.
EDIT: digging deeper I see the END keymap had macros in some places and also one for alt-tab. That works indeed to allow arrow navigation, but the Alt-Tab is not sticky any longer. So that part is then broken.
I also assume that the extra macros and definitions on the base layer were accidental and do not belong to the example. Otherwise my base layer would be broken and not allow text input on the SDF-keys (QWERTY location).
I could apply the modified held MOD space definition and the Alt-Tab macro in my keymap and got it working as wanted, except the Alt not being sticky as it seems, so Alt-Tabing a second time will go back to the windows and not cycle between the Alt-Tab tabs overview.
Those arrows are mapped on the mod layer of the ARR keymap.
Then there is a mod-layer with the same. I do not see or understand how that relates to your âoverlayLayerâ you mention.
overlayLayer takes that keymap and maps its non-empty actions into the first-argument layer.
digging deeper I see the END keymap had macros in some places and also one for alt-tab.
Sorry. They were accident that I used for debugging.
The impoortant one is the one mapped in END.base.leftSpace(Mouse) and the alt+tab macro bound in the mod layer.
I could apply the modified held MOD space definition and the Alt-Tab macro in my keymap and got it working as wanted, except the Alt not being sticky as it seems, so Alt-Tabing a second time will go back to the windows and not cycle between the Alt-Tab tabs overview.
Well, that might be because because overlayLayer mod ARR mod interrupts the hold. What if you replace it by this?
pressKey sLA-tab
overlayLayer mod ARR mod
holdKey sLA-tab
Thanks a lot! The new firmware fixes the problem indeed. I am using the latest macro you shared btw.
I can now navigate with the arrow keys while being in the alt-tab state. I do not really understand why the workaround is needed and in QMK and Kanata that âjust worksâ, but that is likely to the internal structure of the UHK firmware.
I have one minor problem left. I use Ctrl-W to close a tab in the alt-tab view as well. Ctrl-W is also on the mod layer. I added that to the arrow/alt-tab keymap and in the same way like with the arrow added the key to become the ALT-ed version: Alt-Ctrl-W. The tab / program is indeed closing correctly, but at the same time stops with the Alt-tab mode and falls back to the desktop, while I would expect that like with using the arrow-keys I would stay in the Alt-Tab mode. Is that yet another bug or an unsupported feature needed?
Actually this sounds as supported, but intentionally non-default behavior.
I can now navigate with the arrow keys while being in the alt-tab state. I do not really understand why the workaround is needed and in QMK and Kanata that âjust worksâ, but that is likely to the internal structure of the UHK firmware.
I should stress that in your UHK config, you have bound plain arrows in your mod layer, not alt+arrows.
If QMK/Kanata âjust worksâ witn plain arrow bindings, then I am very interested in what their reasoning and specification is, and also how much usecase-specialized thing it is[1]. Can you post links to specifications to that feature by chance?
I use Ctrl-W to close a tab in the alt-tab view as well. Ctrl-W is also on the mod layer.
Right. The so called âsticky modsâ can be potentially very intrusive. For that reason, we apply them only to certain shortcuts that they are typical for. Alt+Tab and Alt+arrows are such ones.
Options:
in your $onInit: set stickyModifiers always
or map them explicitly just for the ctrl+alt+w key, via a macro in the ARR.mod layer: holdKey sLCLA-w
QMK often implements specialized behaviors that assume a specific usecase and environment setup, and then work only for that one usecase and setup. Our macro engine is built more around the idea of providing small building blocks that can be used to adapt to arbitrary usecases without us having to know,assume,design,maintain code for a fixed usecase. âŠď¸
Thanks! That finalizes the solution! I was thinking if I would need to use a macro, but did not try, because the arrow-keys are realized without a macro. So I thought it must work with Ctrl-w in the same way.
If QMK/Kanata âjust worksâ witn plain arrow bindings, then I am very interested in what their reasoning and specification is
Maybe I was not clear enough. Both QMK and Kanata need to have some extra code for Alt-Tab being usable in a meaningful way on a layer [1]. But once that is in place the arrows, Ctrl-w and so on on the layer (with Alt-tab being active) âjust workâ. Indeed the arrows on the nav-layer are defined as plain arrows, without alt (except another pair I have with Alt, which is the shortcut for forwards/ backwards in most browsers and many programs).
That makes sense. There are quite a few special or edge cases when implementing keyboard remapping, which are not obvious at first glance, but can become really tricky.
But your suggested workaround now works great and letâs me use the UHK exactly in the same way like my laptop (Kanata) or QMK powered keyboard. Thanks for your help with that!
[1] That was what I found out after having Alt-Tab on the UHK just working out of the box â which I think has shown that the default setup was real-world-tested and makes sense. In contrast to the default setup of a Voyager, which â at least when I was trying it â did not allow a satisfying keyboard experience.
Both QMK and Kanata need to have some extra code for Alt-Tab being usable in a meaningful way on a layer [1].
Right. Having code on that alt+tab macro that extends the alt activation until layer is exitted would be another way this could be implemented on UHK.
I am wondering if we should provide some better direct support for that behavior, but goven that this is the first request of the kind so far as I remember⌠probably not yet.
To be able to use alt-tab on a layer you cannot directly assign alt-tab in Kanata. See the latest kanata config in my Anymak repo.
Do you use Alt-tab with a separate Alt and Tab key? I liked the UHK approach on a layer and even use the same key position
;; Virtual keys
(defvirtualkeys alt lalt ) ;; needed for alt-tab to work on layer, realized with multi and macro definitions
;; Navigation and shorcut layer
spacefn (tap-hold-release $tap-timeout-zero $hold-timeout-nav spc (multi (layer-while-held navigation) (on-release release-virtualkey alt) )) ;; multi needed for alt-tab on layer
alttab (macro (on-press press-virtualkey alt) 2 tab) ;; needs a short delay to not trigger tab on the first press - 1 is fine, 5 to be on the safe side
I more or less accidentally found out that I can use the arrows and Ctrl-w, while the Alt-Tab overview is active. Most people will not be aware of that â and that is such a nice feature to have (assuming you use a similar navigation/ shortcut layer like I do). Because it is such a frequent task to use Alt-Tab to switch between programs, it quickly became one of my favorite features.
So yes, you do not âneedâ to implement that native. But if you do you could promote it as a real cool addition to the UHK toolbox. Would be worth a newsletter IMO. But likely a video would be best. I just do not have a working solution right now to display the keys I tap on the screen (like the visualization program [Keymap was the name if I recall correct, I sold my Voyager] from ZSA). That would be best to show how it works. I will check out the QMK solution for that. The Kanata based solution does not show my bottom-row-mods or mod-layer (SpaceFn) keys
Before continuing, please flash this build: 
.