I'm gonna be traveling, @Harley Acheson (harley) will take a stab at the windows support.

MS also recommends using a hook to eat the windows key events, should be fairly straight forward to adapt the technique they show here

https://docs.microsoft.com/en-us/windows/win32/dxtecharts/disabling-shortcut-keys-in-games#disable-the-windows-key-with-a-keyboard-hook

Hmmm... might be missing something here...

My understanding is that you want to allow a Windows user to press the OSKey (Windows key) in place of MMB when users are using a pointing device that does not have MMB or is inconvenient. But we can't just deal with this key in our normal way because the operating system is intercepting it at a lower level so that it can do special things with it.

The example you linked (and other similar docs I have found) is creating a keyboard driver hook that swallows the keypress before the operating system can see it. Which is a great way to disable that key when your application is a game, for example.

But that does not result in being able to then detect the OSKey press in order for it to be used in place of MMB. It just makes it like the key was never pressed so it never makes it to our event queue at all.

The ms sample code just eats the event, but you could do other things as well in that handler, i'd probably try calling the original handler which does take a hwnd. GetActiveWindow should get you the right one given you check if we're activated

In D5682#130355, @Harley Acheson (harley) wrote:

Hmmm... might be missing something here...

My understanding is that you want to allow a Windows user to press the OSKey (Windows key) in place of MMB when users are using a pointing device that does not have MMB or is inconvenient.

Yes, when used with left mouse button.

I'm not sure exactly how this should be implemented. Ideally tapping Windows key would still open the start menu.

Implementation looks fine to me, besides the Windows issue.

On Ubuntu tapping the os-key shows all windows, but combining it with clicking or shortcuts works ok. On Windows it still opens the start menu after clicking with the mouse.

Testing this with GNOME, I can't get it to work, even with the windows key being freed from window actions.

I played with this for a few nights, and there doesn't seem to be a nice solution for this on windows.

The only way to reject/eat the keystrokes that prevent the start menu from popping up is a low level keyboard hook.

now it's poorly documented but it's easy to bump into other people having the exact same issue

with the issue being when you use raw input (like we do) windows won't call the hook unless your application has lost the focus, which makes it complete and utterly useless.

However even if the hook did work (which it doesn't) we want to eat some of the keystrokes but not others, we still want the user to be able to use win+e for instance to open up the windows explorer, and just win should still open up the start menu, but not always for instance when we emulated a 3 button mouse however at the level of ghost where this lives, there is no way to tell if the upper levels will/has handle(d) the event or not, so there's no way to know if a stroke should be blocked or not.

The key is called the OS key, i guess this is for a reason, and i'm starting to believe that trying to re-purpose it for application oriented tasks it is just asking for trouble.

@Julian Eisel (Severin) there are enough different desktop environments on Linux that think we have to leave it to the user to configure their system so it works.

Still, it's a shame that this is a hassle to configure with Gnome which is a popular DE.

Committed rBd596a6368cc62d198dd33dadd1cd0831d0de3dee

This is currently disabled for Windows.