FancyWM / fancywm

FancyWM - Dynamic Tiling Window Manager for Windows
GNU General Public License v2.0
692 stars 26 forks source link

FancyWM taking over keybinds that are not configured/assigned - breaking other app keybinds #252

Open tubes41 opened 3 months ago

tubes41 commented 3 months ago

Describe the bug "Unrecognized Keybinding" warning taking over existing AHK keybinds when Ctrl+Enter is in script ( +{enter} )

To Reproduce Steps to reproduce the behavior:

  1. Create an AHK script that sends keystrokes based on a keybind that is not in fancywm (example below)
  2. Run AHK script
  3. Press AHK keybind (Win+F1 in example)
  4. Popup noting "Unrecognized Keybinding" steals focus of current window, interrupting AHK sent keystrokes to window with original focus

Example AHK script:

Requires AutoHotkey v2.0

A_MenuMaskKey := "vkFF" ; Change the masking key to something unassigned such as vkFF.

F1::Send "Lorem ipsum dolor sit amet+{enter}Consectetur adipiscing elit. Proin mattis est nisi, at eleifend massa venenatis sodales. Nam pellentesque dui vel quam lobortis tincidunt. Donec eu dictum nisi, eu interdum risus. Donec mollis a dui id tincidunt."

Expected behavior fancyWM to ignore keybind as it is not assigned.

Screenshots image

Desktop (please complete the following information):

veselink1 commented 3 months ago

I wonder if AHK ends up generating the Activation hotkey keypress. I see the A_MenuMaskKey will mask Win and Alt keys. And the text here contains capitals, which probably generate Shift + Letter keypresses.

If that is the case, then the best option would be to use another activation hotkey.

veselink1 commented 3 months ago

Did you managed to resolve this?

tubes41 commented 2 months ago

I changed the activation hotkey to be caps-lock as a workaround in the meantime, but I have noticed that the alt or ctrl keys are randomly getting latched down? I think this may be a AHK problem that I'll need to investigate further. Once the script issue is sorted, I'll revisit this and confirm if focus is still stolen incorrectly by FancyWM.

tubes41 commented 2 months ago

Okay, finally figured it out. AHK is having issues masking / buffering the input keys during the send command: https://www.autohotkey.com/docs/v2/lib/Send.htm#Send_variants This ends up causing the activation hotkey (Win key in this case) and the mask key (Shift by default) to be occasionally latched down and not masked during the send command. This normally isn't a problem, as the shift key is used to mask the hotkeys, but the Shift+Win key combo is what was used by default by FancyWM.

I'll raise an issue with the AHK team. If anyone needs a temporary workaround for this, just add {LWin up}{RWin up} to the start of your send command.