Repository navigation
Desktop Switching
Pressing a hotkey switches to its target desktop. There are two modes, chosen by the
SmoothSwitch setting in config.json.
Synthesizes the built-in Windows shortcut Win+Ctrl+←/→, one step at a time, until it
reaches the target. This produces exactly the same animation as switching by keyboard and
does not flicker the taskbar.
Because Win+Ctrl+Arrow only moves to an adjacent desktop, a far jump passes through the
desktops in between — e.g. 1 → 5 slides through 2, 3, 4. This is expected. Each step waits
for Windows to confirm the move (the registry updates with a short lag) before sending the
next, so far jumps take about a second per step.
Best for: users who value the smooth animation and a flicker-free taskbar, and who mostly switch between nearby desktops.
Jumps straight to the target via the undocumented internal COM interface
IVirtualDesktopManagerInternal.SwitchDesktop — no stepping through intermediates, instant
even for far jumps.
The trade-off: the un-animated switch can make the taskbar buttons flicker briefly on some systems (the overlay itself is pinned to all desktops, so it doesn't flicker). If the internal interface is unavailable on your Windows build, the app falls back to smooth stepping for that switch and retries the direct path on the next hotkey.
Best for: users who frequently jump across many desktops and want instant navigation.
| Smooth (default) | Direct | |
|---|---|---|
| Far jump (1→5) | steps through 2,3,4 | instant |
| Taskbar flicker | none | possible |
| Animation | native slide | none |
| API stability | built-in shortcut, always works | undocumented COM, auto-falls back |
Switch modes in the settings window (Smooth switch checkbox) or by editing SmoothSwitch
in config.json and choosing Reload config.
Earlier versions latched permanently to stepping after a single transient failure of the
internal COM interface (e.g. a momentary shell hiccup or an explorer.exe restart): once it
failed, every later jump fell back to stepping for the rest of the session, so direct jumps
"worked at first, then walked through the middle desktops forever."
This is fixed — a transient failure now falls back for that one jump only and retries the direct path on the next hotkey. Only a genuinely-absent interface (unsupported Windows build) stays on stepping.
The current desktop / count / name is read directly from the registry
(…\Explorer\VirtualDesktops\VirtualDesktopIDs order list + CurrentVirtualDesktop). This
doesn't depend on private COM, so it keeps working across Windows builds. The overlay is shown
on every desktop via the documented public COM IVirtualDesktopManager.MoveWindowToDesktop
(stable since Windows 10 1607).
See Troubleshooting if switching is slow, stuck, or flickers.