starred/komorebi
1
0
Fork 0
mirror of https://github.com/LGUG2Z/komorebi.git synced 2026-01-11 14:40:25 +01:00
Code Issues 87 Packages Projects Releases 10 Wiki Activity

[BUG]: Using WHKD and mostly default Komorebi alt key sticks between monitor changes #273

New Issue
Closed
opened 2026-01-05 14:49:24 +01:00 by adam · 6 comments
adam commented 2026-01-05 14:49:24 +01:00
Owner
Copy Link

Originally created by @allora on GitHub (Dec 11, 2023).

Describe the bug
When using a mostly default Komorebi config and the default suggested whkd, When using Alt + HJKL to navigate to windows on a different monitor, then switching its workspace/desktop to another workspace/desktop on that monitor makes the alt key stick 100% of the time.

By "Stick" i mean that alt is registered as held, even though I am not pressing anything on the keyboard or mouse. In firefox, this manifests as downloading links when I click on them.

To resolve this I have to navigate to another window with ALT + HJKL and back to the window I want to use.

To Reproduce
Steps to reproduce the behavior:

  1. Have Komorebic and multiple monitors
  2. Have more than one desktop on each display, and apps open on each
  3. Change desktops on monitor 1
  4. Now try typing in a text field in the window you land on in that monitor

Expected behavior
No matter where i switch to, different monitor, window, etc. I expect that alt is not "stuck" on.

Screenshots and Videos
None atm. I can try to get something if needed.

Operating System
Provide the output of systeminfo | grep "^OS Name\|^OS Version"

OS Name:                   Microsoft Windows 10 Pro
OS Version:                10.0.19045 N/A Build 19045

komorebic check Output
Provide the output of komorebic check

No KOMOREBI_CONFIG_HOME detected, defaulting to C:\Users\Allie

Looking for configuration files in C:\Users\Allie

No komorebi configuration found in C:\Users\Allie

If running 'komorebic start --await-configuration', you will manually have to call the following command to begin tiling: komorebic complete-configuration

Additional context
I have multiple displays and a fair number of windows up for work (slack, discord, multiple browser windows, internal chat services and unity/rider

Originally created by @allora on GitHub (Dec 11, 2023). **Describe the bug** When using a mostly default Komorebi config and the default suggested whkd, When using Alt + HJKL to navigate to windows on a different monitor, then switching its workspace/desktop to another workspace/desktop on that monitor makes the alt key stick 100% of the time. By "Stick" i mean that alt is registered as held, even though I am not pressing anything on the keyboard or mouse. In firefox, this manifests as downloading links when I click on them. To resolve this I have to navigate to another window with ALT + HJKL and back to the window I want to use. **To Reproduce** Steps to reproduce the behavior: 1. Have Komorebic and multiple monitors 2. Have more than one desktop on each display, and apps open on each 3. Change desktops on monitor 1 4. Now try typing in a text field in the window you land on in that monitor **Expected behavior** No matter where i switch to, different monitor, window, etc. I expect that alt is not "stuck" on. **Screenshots and Videos** None atm. I can try to get something if needed. **Operating System** Provide the output of `systeminfo | grep "^OS Name\|^OS Version"` ``` OS Name: Microsoft Windows 10 Pro OS Version: 10.0.19045 N/A Build 19045 ``` **`komorebic check` Output** Provide the output of `komorebic check` ``` No KOMOREBI_CONFIG_HOME detected, defaulting to C:\Users\Allie Looking for configuration files in C:\Users\Allie No komorebi configuration found in C:\Users\Allie If running 'komorebic start --await-configuration', you will manually have to call the following command to begin tiling: komorebic complete-configuration ``` **Additional context** I have multiple displays and a fair number of windows up for work (slack, discord, multiple browser windows, internal chat services and unity/rider
adam added the bug label 2026-01-05 14:49:24 +01:00
adam closed this issue 2026-01-05 14:49:24 +01:00
adam commented 2026-01-05 14:49:24 +01:00
Author
Owner
Copy Link

@LGUG2Z commented on GitHub (Dec 12, 2023):

Hi @allora this is an issue that is known to impact a minority of users when they have alt_focus_hack enabled in the config.

You may want to check out any commit after this one: e04ba0e033

This commit (or any commit after it on the master branch) implements a different approach to focus changing that doesn't rely on alt_focus_hack (ie. it can be set to false) - I am currently using this as are a number of users on the Discord to good results.

This will be rolled out in the next release, which will most likely be in early January, but you can grab the prebuilt binaries from the latest actions job to try it out locally too if you are not in a position to build from source.

@LGUG2Z commented on GitHub (Dec 12, 2023): Hi @allora this is an issue that is known to impact a minority of users when they have `alt_focus_hack` enabled in the config. You may want to check out any commit after this one: https://github.com/LGUG2Z/komorebi/commit/e04ba0e033c4515095d1290019b21bec7a644204 This commit (or any commit after it on the `master` branch) implements a different approach to focus changing that doesn't rely on `alt_focus_hack` (ie. it can be set to `false`) - I am currently using this as are a number of users on the Discord to good results. This will be rolled out in the next release, which will most likely be in early January, but you can grab the prebuilt binaries from the latest [actions job](https://github.com/LGUG2Z/komorebi/actions/runs/7079319282) to try it out locally too if you are not in a position to build from source.
adam commented 2026-01-05 14:49:24 +01:00
Author
Owner
Copy Link

@allora commented on GitHub (Dec 12, 2023):

I'm pretty much just using the defaults.. i never set an "alt focus hack" is there a way to see if its enabled?

@allora commented on GitHub (Dec 12, 2023): I'm pretty much just using the defaults.. i never set an "alt focus hack" is there a way to see if its enabled?
adam commented 2026-01-05 14:49:24 +01:00
Author
Owner
Copy Link

@LGUG2Z commented on GitHub (Dec 12, 2023):

It's enabled by default in the example config from the latest release: https://github.com/LGUG2Z/komorebi/blob/master/komorebi.example.json#L6

@LGUG2Z commented on GitHub (Dec 12, 2023): It's enabled by default in the example config from the latest release: https://github.com/LGUG2Z/komorebi/blob/master/komorebi.example.json#L6
adam commented 2026-01-05 14:49:25 +01:00
Author
Owner
Copy Link

@allora commented on GitHub (Dec 13, 2023):

Awesome thanks! When i get time ill test out the new build and report back

@allora commented on GitHub (Dec 13, 2023): Awesome thanks! When i get time ill test out the new build and report back
adam commented 2026-01-05 14:49:25 +01:00
Author
Owner
Copy Link

@cubeDHS2017 commented on GitHub (Dec 21, 2023):

I came across this issues and decided to try using AutoHotKey to manage all of my keyboard shortcuts. Using AutoHotKey I have not had this issue with the alt key getting stuck. The other reason why it might have been fixed is because I have changed over to use the Windows key as my main modifier key (win key + 1 to go to first workspace). Since I have made these changes the alt key sticking has not been a problem.

@cubeDHS2017 commented on GitHub (Dec 21, 2023): I came across this issues and decided to try using AutoHotKey to manage all of my keyboard shortcuts. Using AutoHotKey I have not had this issue with the alt key getting stuck. The other reason why it might have been fixed is because I have changed over to use the Windows key as my main modifier key (win key + 1 to go to first workspace). Since I have made these changes the alt key sticking has not been a problem.
adam commented 2026-01-05 14:49:25 +01:00
Author
Owner
Copy Link

@LGUG2Z commented on GitHub (May 12, 2024):

alt_focus_hack has been deprecated for a while now

@LGUG2Z commented on GitHub (May 12, 2024): `alt_focus_hack` has been deprecated for a while now
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
0.1.36
apps-behaving-badly
bug
bug
cannot-reproduce
documentation
enhancement
github_actions
i-am-stuck
i-will-definitely-work-on-this
i-will-not-work-on-this
i-will-probably-work-on-this
komorebi
komorebi-bar
komorebic
performance
pull-request
Mirrored from GitHub Pull Request
 translation
No Label bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/komorebi#273
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?