Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

issue with win combination keys? #158

Closed
rainsia opened this issue Oct 29, 2022 · 9 comments
Closed

issue with win combination keys? #158

rainsia opened this issue Oct 29, 2022 · 9 comments

Comments

@rainsia
Copy link

rainsia commented Oct 29, 2022

GlazeWM is the best twm on Windows. I use it daily.

Howevery, I encounter a problem on Windows 10.

When I use some [win] combination keys, for example, [LWin + R] or [LWin+=], if GlazeWM (version 1.8.1) is running, the start menu will show up.

For example, when I pressed [Win + R], the "Run dialog" did show up, but subsequently, the windows start menu will also show up.

I tried several key combinations, I guess the key combinations which start a floating dialog should also trigger the start menu.

@ParasiteDelta
Copy link
Contributor

Can confirm, it's a bit weird how triggers the start menu for these commands. Unfortunately, I haven't found a solution other than to map the commands I'm most likely to use to keybinds in GWM. Of course, I wonder if you could just create a keybind in GWM to open the Run prompt...

@Vernetzt
Copy link

Throwing my hat in the pile. I make pretty heavy use of the Windows key as a modifier so would love to see this resolved.
Looked through the relevant keybinding stuff but nothing popped out as the reason sadly.

@kavishkagihan
Copy link

I faced the exact same issue. I was able to get it somewhat under control by disabling the default windows shortcuts (because I don't use those that often, I mapped what I use i.e Win+e in my glaze config) so that I can map them to whatever I want.

  - command: "exec explorer"
    binding: "LWin+E"

But I wasn't able to solve the issue where the windows search menu popps up whenever I switch workspaces with Win+<num>. But theoretically, this is resolvable if replace the windows explorer itself with a custom shell by editing the registry key WinLogon as I presume.

@kavishkagihan
Copy link

kavishkagihan commented Feb 8, 2023

Finally I was able to fix this issue the this AutoHotKey script

One thing to note here is that when switching workspaces you won't be able to switch 2 or more workspaces in a row while holding the Win key. You will have to press Win+1 or Win+2 etc from the beginning every time

update: if you have a multi-monitor setup, when you switch between the current workplace on 1 monitor to the current workspace on the other, the start menu will pop up, Therefore, to minimize that you can edit the script slightly like this #1::Send {Blind}{LWin Down}1{LWin Up}{Esc}

@chalist
Copy link

chalist commented Oct 20, 2023

your answer does not work for me! Start menu display every other switching!

So I used Windows PowerToys Keyboard Manager (thanks to Rasmus's answer) to remap LWin to Alt; everything is fine now.

Also, I need the Win key, so remap right alt to the win key for emergency use cases :))

sounds stupid, but works fine!

@richcarl
Copy link

richcarl commented Jul 11, 2024

I'm a heavy Emacs user and need the Alt key for that, so I wanted to use LWin for Glaze. Tried every variant of AutoHotKey scripts that I could find, but none of them could prevent the Start menu from popping up constantly. I think Glaze is doing something wrong somewhere, because it seems that when Glaze decides not to take any action - like trying to move focus downwards when you're already at the bottommost window - the Search Menu does not pop up, but when Glaze does take an action, it's as if this causes an LWin key event to leak through.

A workaround I finally found that worked for me, is to map (using SharpKeys) the Left Control key to send a Right Control key code, and then use RControlKey as the main modifier in the Glaze config. Since I always map Caps Lock to be Left Control anyway, and rarely use Right Control for anything normally, this works fine and leaves LWin unchanged.

@lars-berger
Copy link
Member

Fixed in v3 👍 Latest release

@richcarl
Copy link

Tried in 3.1.1, but the behaviour persists, e.g. the following:

- commands: ['focus --next-workspace']
    bindings: ['LWin+.']

does switch to the next workspace, but the Windows Search menu also pops up.

@lars-berger
Copy link
Member

Tried in 3.1.1, but the behaviour persists, e.g. the following:

- commands: ['focus --next-workspace']
    bindings: ['LWin+.']

does switch to the next workspace, but the Windows Search menu also pops up.

This a related but different issue. There was a bug in v2 where any time you pressed a win combination key (eg lwin+r) it would open the start menu. This happened with the default keybindings without using lwin in bindings. Fix is in progress for the problem you mentioned you though, will be in the next release shortly

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants