mirror of
https://github.com/LGUG2Z/komorebi.git
synced 2026-01-11 14:40:25 +01:00
[FEAT]: Windows Virtual Desktop Support #232
Reference in New Issue
Block a user
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?
Originally created by @pulleee on GitHub (Jul 26, 2023).
As windows already supports Virtual Desktops - it would be nice to have komorebi work on these too.
@LGUG2Z commented on GitHub (Jul 27, 2023):
Unfortunately this is up to the Windows team.
If/when Microsoft reverses their position (https://devblogs.microsoft.com/oldnewthing/20201123-00/?p=104476) and adds a complete API for VD to Win32, I can look into adding support.
Regarding reverse engineered APIs for VDs that you may have seen elsewhere; these frequently break with Windows updates and are not stable enough to include in this codebase.
@btvoidx commented on GitHub (Aug 18, 2023):
I have found this Powershell module https://github.com/MScholtes/PSVirtualDesktop, which would allow to switch desktops via whkd. I am yet to set it up and try, but it may work.
I've been using FancyWM lately due to it not implementing workspaces by itself and just using virtual desktops, (which works wonderfully with fullscreen apps and games!) but I find its lack of automatic BSP layout very unappealing.
Really hoping Microsoft or @LGUG2Z change their mind about Virtual Desktops (whoever does it first, I don't really care as a consumer). Thank you so much for all work on komorebi, it's awesome!
@tommdq commented on GitHub (Jan 23, 2024):
Any updates on this? I'm new to komorebi but so used to windows virtual desktops, I'm not able to make komorebi work in more than one virtual desktop!
@LGUG2Z commented on GitHub (Jan 23, 2024):
This will forever remain an issue that needs to be resolved by the multi trillion dollar company, not a single unemployed solo dev. 😅
If anyone wants to see movement on this, I suggest reaching out to people who work on the Windows desktop team(s) at Microsoft, especially product managers, about exposing a fully functional and stable VD API in Win32.
@LGUG2Z commented on GitHub (Feb 15, 2024):
I have made an video explaining why Virtual Desktops support will likely not be feasible for the foreseeable future: https://www.youtube.com/watch?v=2_daNZl5Rw0
@LGUG2Z commented on GitHub (May 12, 2024):
Closing this out as there is nothing to be done; this can be re-opened if any of you notice that the Win32 has been updated to allow people to build on top of VDs.
@rp1231 commented on GitHub (May 20, 2024):
https://github.com/FuPeiJiang/VD.ahk
Found this ahk library for virtual desktops, Posting it here just in case it's useful.
@rp1231 commented on GitHub (May 20, 2024):
Also found this app https://github.com/Grabacr07/SylphyHorn?tab=readme-ov-file
Which uses global windows hooks to transport a window from one virtual desktop to another.
This is the blog where this is mentioned
https://grabacr-net.translate.goog/archives/5701?_x_tr_sch=http&_x_tr_sl=auto&_x_tr_tl=en&_x_tr_hl=en-US&_x_tr_pto=wapp
@LGUG2Z commented on GitHub (May 20, 2024):
Unfortunately these both suffer from the same issues I discussed here: https://www.youtube.com/watch?v=2_daNZl5Rw0
Let's keep updates to this thread to updates to the Win32 API, because whatever new or old applications people find interacting with virtual desktops will all have the same fundamental problem of unstable com interfaces that regularly break across even small Windows Updates.
@GTonehour commented on GitHub (May 6, 2025):
I understand your position, I just want to articulate an additional use case regarding this issue, for completeness.
Windows has a setting under System > Multitasking > Desktops called 'On the taskbar, show all the open windows...' with options for 'On all desktops' or 'Only on the desktop I'm using'.
Users typically use workspaces (or virtual desktops) to create manageable subsets of windows; specifically, that last setting is expected to limit Alt+Tab and the taskbar to that subset.
Alt+Tab seems like a valid use-case even in a TWM context, to reach minimized windows or provide a UI to pick a window in the stack.
GlazeWM doesn't officially support virtual desktops (https://github.com/glzr-io/glazewm/issues/671) but they apparently manage to update windows in Alt+Tab and the taskbar when changing workspaces.
@LGUG2Z commented on GitHub (May 6, 2025):
This is definitely not my expectation - I want to have alt+tab go through all windows on every workspace (and switch to the appropriate workspace if necessary when making a selection), same for the taskbar
Anyone is welcome to submit a patch to add a configuration option which introduces a different opt-in behaviour as long as it doesn't break backwards compatibility, even for anti-features like what is being described here 😅
@curbe454 commented on GitHub (Aug 13, 2025):
Could we just give up the Virtual Desktop and use a new? Implementing a new "komorebi virtual desktop" is just like setting up a layer above the workspaces but with alike logic.
What's we would lost is just touch screen operation of Windows Virtual Desktop. For the rest(shortcuts), it's eazy to deal with. Just disable them.
As a user, I really want some isolated sets of workspace groups (where the sets are called "virtual desktops" by Microsoft). And I don't mind if it's not Windows Virtual Desktop.