[FEAT]: Support for switching to the next/previous monitor regardless of an application being open on it #292

New Issue

2026-01-05T14:49:32+01:00

adam commented

2026-01-05 14:49:32 +01:00

Originally created by @dbaxa on GitHub (Feb 7, 2024).

Is your feature request related to a problem? Please describe.
As a awesomewm user who is sometimes using windows
When I press a shortcut similar to say windows + control + k/j I would like to move to the next/prev monitor (respectively).

Describe the solution you'd like
The ability to switch which monitor & application (if an application is currently displayed on the switched to monitor) is currently in focus/use.

Describe alternatives you've considered
I tried using a combination of komorebi, yasb, & https://github.com/klesh/JigsawWM (with the following config for hotkeys in JigsawWM

    ([Vk.WIN, Vk.CONTROL, Vk.J], wm.prev_monitor),

). However, this doesn't work very well as keys often get stuck due to competing programs and differing window management implementations.

Additional context
I hope that I have provided sufficient information for this request. I do not that the follow focus option could be of assistance with regards to changing monitors. Additionally, by "changing monitors" I mean that the mouse is sent to a next/previous monitor & focus "follows" it.

Originally created by @dbaxa on GitHub (Feb 7, 2024). **Is your feature request related to a problem? Please describe.** As a `awesomewm` user who is sometimes using windows When I press a shortcut similar to say windows + control + k/j I would like to move to the next/prev monitor (respectively). **Describe the solution you'd like** The ability to switch which monitor & application (if an application is currently displayed on the switched to monitor) is currently in focus/use. **Describe alternatives you've considered** I tried using a combination of komorebi, yasb, & https://github.com/klesh/JigsawWM (with the following config for hotkeys in JigsawWM ``` ([Vk.WIN, Vk.CONTROL, Vk.K], wm.next_monitor), ([Vk.WIN, Vk.CONTROL, Vk.J], wm.prev_monitor), ``` ). However, this doesn't work very well as keys often get stuck due to competing programs and differing window management implementations. **Additional context** I hope that I have provided sufficient information for this request. I do not that the follow focus option could be of assistance with regards to changing monitors. Additionally, by "changing monitors" I mean that the mouse is sent to a next/previous monitor & focus "follows" it.

adam added the enhancement label 2026-01-05 14:49:32 +01:00

adam closed this issue

2026-01-05 14:49:32 +01:00

adam commented

2026-01-05 14:49:33 +01:00

@gazpachoking commented on GitHub (Feb 7, 2024):

Does komorebic cycle-monitor next/previous not do that already? You can bind that to whatever hotkey you need with whkd or autohotkey.

@gazpachoking commented on GitHub (Feb 7, 2024): Does `komorebic cycle-monitor next/previous` not do that already? You can bind that to whatever hotkey you need with whkd or autohotkey.

adam commented

2026-01-05 14:49:33 +01:00

@dbaxa commented on GitHub (Feb 8, 2024):

@gazpachoking I didn't know about komorebic cycle-monitor next/previous . It looks like I need a combination of cycle-monitor and focus - in a direction (usually up). The follow mouse focus doesn't seem to work for this use case.

@dbaxa commented on GitHub (Feb 8, 2024): @gazpachoking I didn't know about `komorebic cycle-monitor next/previous` . It looks like I need a combination of cycle-monitor and focus - in a direction (usually up). The follow mouse focus doesn't seem to work for this use case.

adam commented

2026-01-05 14:49:33 +01:00

@dbaxa commented on GitHub (Mar 8, 2024):

I have this mostly working, there is an issue with regards to WSL applications not playing nice with focus switches between monitors ...

Steps to reproduce
0. Have multiple monitors plugged in & have the following autohotkey script setup & running

#Requires AutoHotkey v2.0

#^j:: {
	RunWait "komorebic.exe cycle-monitor previous",, "Hide"
	Run "komorebic.exe force-focus",,"Hide"

	
	
 }
#^k:: {
	RunWait "komorebic.exe cycle-monitor next",, "Hide"
	Run "komorebic.exe force-focus",, "Hide"

 }

Open a gui application via WSL e.g. gedit on the same monitor that you have another application open at the same time
Have gedit open above / in focus on the monitor
Switch to the next monitor (I have a browser open on the other monitor but it likely doesn't matter if the next monitor has an app open on it or not)
Try to switch back to previous monitor & have gedit in focus
Gedit is hidden and isn't brought into focus

Step 6 should end up with Gedit is back in focus but it ends up being hidden/not in focus.

@dbaxa commented on GitHub (Mar 8, 2024): I have this mostly working, there is an issue with regards to WSL applications not playing nice with focus switches between monitors ... Steps to reproduce 0. Have multiple monitors plugged in & have the following autohotkey script setup & running ``` #Requires AutoHotkey v2.0 #^j:: { RunWait "komorebic.exe cycle-monitor previous",, "Hide" Run "komorebic.exe force-focus",,"Hide" } #^k:: { RunWait "komorebic.exe cycle-monitor next",, "Hide" Run "komorebic.exe force-focus",, "Hide" } ``` 2. Open a gui application via WSL e.g. gedit on the same monitor that you have another application open at the same time 3. Have gedit open above / in focus on the monitor 4. Switch to the next monitor (I have a browser open on the other monitor but it likely doesn't matter if the next monitor has an app open on it or not) 5. Try to switch back to previous monitor & have gedit in focus 6. Gedit is hidden and isn't brought into focus Step 6 should end up with Gedit is back in focus but it ends up being hidden/not in focus.

adam commented

2026-01-05 14:49:33 +01:00

@LGUG2Z commented on GitHub (Mar 8, 2024):

WSLg has not been supported for a while (they initially had a decent implementation, then they made a bunch of breaking changes, and now whatever they have results in WSLg windows not responding properly to basic Win32 window positioning API calls).

I suggest using VcXsrv (scoop install vcxsrv), which is fully supported by komorebi and also correctly responds to Win32 window positioning API calls.

Basic setup guide:

Launch with Xlauncher.exe
Default settings until the final screen, where you need to disable "disable access control"
Add export DISPLAY="$(ip route | awk '/^default/{print $3}'):0.0" to your shell init
Add export LIBGL_ALWAYS_INDIRECT=1 to your shell init
Set guiApplications=false in $Env:USERPROFILE\.wslconfig
Restart WSL VMs for all changes to take effect

@LGUG2Z commented on GitHub (Mar 8, 2024): WSLg has not been supported for a while (they initially had a decent implementation, then they made a bunch of breaking changes, and now whatever they have results in WSLg windows not responding properly to basic Win32 window positioning API calls). I suggest using VcXsrv (`scoop install vcxsrv`), which is fully supported by `komorebi` and also correctly responds to Win32 window positioning API calls. Basic setup guide: * Launch with Xlauncher.exe * Default settings until the final screen, where you need to disable "disable access control" * Add `export DISPLAY="$(ip route | awk '/^default/{print $3}'):0.0"` to your shell init * Add `export LIBGL_ALWAYS_INDIRECT=1` to your shell init * Set `guiApplications=false` in `$Env:USERPROFILE\.wslconfig` * Restart WSL VMs for all changes to take effect

adam referenced this issue

2026-01-05 14:53:10 +01:00

[PR #292] [MERGED] chore(deps): bump clap from 4.0.22 to 4.0.23 #842

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/komorebi#292