Classic Shell: Forum

Would it be possible to change Shift-Win to act on release rather than press? Right now it can conflict with Shift-Win key combinations, like Shift-Win-Up. It's possible to avoid the action by pressing the Win key first, then Shift, but I do happen to press Shift first in many cases.

If there's a reason for it act on press rather than on release, a configuration option would be the best.

Shift+Win is a hotkey. Hotkeys work on press, not release. Try Win+E for example.
What you can do is press Win+Shift+Up.

I agree. It also conflicts with Shift+Win+Left/Right to move the app across monitors.
In previous versions of Classic Shell, it acted on release because it was implemented using a keyboard filter hook. Now it uses hotkeys. The keyboard filter hook caused some compatibility problems for some users and didn't work if an elevated app had focus. The hotkey gets rid of this but conflicts with other shortcuts.
I guess best way would be to allow the user more flexibility in choosing the hotkey (Ctrl+Win/Shift+Win/Alt+Win or Win+Shift/Win+Alt/Win+Ctrl, or some combination of three, or holding down Winkey?

_________________
Links to some general topics:

● Compare Start Menus

● Read the Search box usage guide.

I am a Windows enthusiast and helped a little with Classic Shell's testing and usability/UX feedback.

But then, WinKey by itself acts on release to open the menu, as it does without Classic Shell to switch to the the Start Screen.

If it's about a hook doing trouble and WM_HOTKEY only being sent on press, I guess that's another sort of problem/dilemma.

There are two problems here:

1) How to detect the key press. One way is with a keyboard hook. But it doesn't work and an elevated application is running because of UIPI.

2) How to bring the menu in foreground. The OS only gives you foreground if you use a hotkey, or if the user clicks on your window. Any other cases are hacky and unreliable. That's why the Hover feature doesn't work 100% - because there is no user action that gives you the right to be in foreground. Keyboard hooks suffer from the same problem. The OS doesn't know that the key is for you and doesn't put you in foreground.

So at the moment the only available controls that solve both problems are the ones available in the settings.

Here are some keyboard shortcuts on Windows that involve Shift/Alt/Ctrl and the Windows key (not necessarily a complete list but which I think may be significantly used):


- Shift+Win+M=Undo minimize all windows previously done by Win+M- Shift+Win+Up=Maximize window vertically
- Shift+Win+Left=Move window to left monitor (when using multiple displays)
- Shift+Win+Right=Move window to right monitor (when using multiple displays)
- Shift+Win+<number>=Open new window of app on the taskbar
- Alt+Win+<number>=Show jumplist of taskbar app
- Ctrl+Win+<number>=Switch to the last active window of app on the taskbar when combining is enabled

The ones with Shift are greater than Alt or Ctrl. So giving Ctrl+Win as an option seems like a good idea.

_________________
Links to some general topics:

● Compare Start Menus

● Read the Search box usage guide.

I am a Windows enthusiast and helped a little with Classic Shell's testing and usability/UX feedback.

How's WinKey handled to both get focus and detect release?

It is handled by the system. The system can do whatever it wants. Individual apps can't.

You mean WinKey by itself is also registered as a hotkey, but that one triggers on release? Interesting.

No, the Win key is not a hotkey. It generates SC_TASKLIST message and does it on release.

In the latest Classic Shell, this is fixed btw. Shift+Win action occurs now on release, rather than press.

_________________
Links to some general topics:

● Compare Start Menus

● Read the Search box usage guide.

I am a Windows enthusiast and helped a little with Classic Shell's testing and usability/UX feedback.