Windows key shortcuts (Win+E, Win+V, Win+1-9 and the like)

Why Win-key shortcuts did not work before

Windows claims a set of Windows-key combinations for the shell before any normal shortcut API can see them. Press Win+E and File Explorer opens; the keystroke never reaches an application that asked for it. Inside Omniscio that showed up as a shortcut you could set in Settings that simply did nothing — the operating system refused it and there was no way around that refusal.

There is one way around it: a keyboard hook, which is what PowerToys and AutoHotkey use. A hook sees a keystroke before the shell does, so it can take the combination for itself. Omniscio now ships one.

How it works, in plain terms

Omniscio always tries the ordinary route first. Only when Windows refuses a shortcut — which is exactly the Windows-key set — does it hand that shortcut to a small helper program that holds the hook. The helper is a separate process with one job, so the tiny bit of work it does for each keystroke never competes with anything else Omniscio is doing.

Two details are worth knowing, because they are what make it feel like a normal shortcut:

• The Start menu stays shut. Taking the Windows key away from Windows is only half the job; Windows still opens its own menu when the key is released. The helper cancels that too.
• A plain Windows-key tap still opens Start. Omniscio cannot know whether you are starting a combination until a moment later, so it takes the key down speculatively and gives it back the instant the combination turns out not to be one it owns. Tapping the Windows key by itself behaves exactly as it always did.

What you give up

The switch sits at the bottom of Settings → Keyboard Shortcuts, in the system-wide section, and its description states the trade. It is on by default.

• You trade the Windows behaviour. While Omniscio owns a chord, that chord does Omniscio's action instead of Windows'. Bind Win+E to something and you lose "open File Explorer" while Omniscio is running.
• Turn the switch off and everything goes back. Immediately, with no restart, and with nothing left running behind it.

What cannot be taken

Stated plainly rather than discovered later:

• Win+L and Ctrl+Alt+Del are handled by Windows below any hook. Nothing can take them, so Omniscio refuses to bind them this way rather than pretending.
• Keys typed into an app running as administrator are invisible to the helper, because Windows blocks a normal program from seeing them. A shortcut taken this way will not fire there.
• When another program uses the same shortcut, the outcome is not guaranteed. Windows refuses the shortcut the same way whether it keeps it for itself or another app registered it, so Omniscio may take it from that app — or lose it to a program with its own hook, such as PowerToys, because Windows promises no order between hooks. The switch copy says so rather than promising either outcome.
• Security software may look twice at hooks. A low-level keyboard hook is the same technique input software uses; some security tools treat it with suspicion.

Where the shortcut shows up

A taken-over shortcut appears in Settings → Keyboard Shortcuts like any other working one — same row, same key pill, no warning. It is deliberately not marked "not active": it is active. If the helper ever fails to start, the row goes back to saying the shortcut is not working, so the app never claims a key works when it does not.

Windows only

The takeover exists only on Windows, where the reserved-chord problem exists. On macOS and Linux nothing changes: Super there is the Command key, and every shortcut keeps using the ordinary route.

Related

• Keyboard shortcuts — the full list of bindings and how to change them, including the system-wide ones this page is about.
• Tray and window — the shortcuts that work while Omniscio is in the background, which is where a taken-over Windows-key chord is set.