fancywm icon indicating copy to clipboard operation
fancywm copied to clipboard
verified publisher icon FancyWM

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

Open tubes41 opened this issue 1 year ago • 4 comments

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):

  • OS: Windows 11
  • OS Build: 22631.3593
  • FancyWM Version: 2.13.0.0

tubes41 avatar May 31 '24 03:05 tubes41

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 avatar Jun 01 '24 11:06 veselink1

Did you managed to resolve this?

veselink1 avatar Jun 08 '24 10:06 veselink1

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 avatar Jun 12 '24 01:06 tubes41

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.

tubes41 avatar Jun 12 '24 06:06 tubes41

This issue is stale because it has been open for 14 days with no activity.

github-actions[bot] avatar Sep 11 '24 02:09 github-actions[bot]

This issue was closed because it has been inactive for 14 days since being marked as stale.

github-actions[bot] avatar Sep 16 '24 02:09 github-actions[bot]

I'm experiencing a similar issue, but with kmonad (keyboard management tool). https://github.com/kmonad/kmonad/issues/886. Keybinds configured via kmonad or AHK are not correctly detected in fancywm. Using a shift+win key-bind configured in kmonad are not properly masked. I'm guessing this is an issue that can only be fixed by modifying whatever low-level hook is used by kmonad, and not something that fancywm is responsible for?

ASong5 avatar Sep 21 '24 21:09 ASong5