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

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

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

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
Author
Owner
Copy Link

@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
Author
Owner
Copy Link

@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
Author
Owner
Copy Link

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

 }
  1. Open a gui application via WSL e.g. gedit on the same monitor that you have another application open at the same time
  2. Have gedit open above / in focus on the monitor
  3. 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)
  4. Try to switch back to previous monitor & have gedit in focus
  5. 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
Author
Owner
Copy Link

@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
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 enhancement
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#292
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?