Treat $mod+mouse key same way as $mod+key

[Mel34]

I occasionally use mouse in conjunction with $mod button to do certain tasks. Even the stock configuration comes with this functionality in mind:

# Drag floating windows by holding down $mod and left mouse button.
    # Resize them with right mouse button + $mod.

I'm currently using wldash as my launcher and I have it bound to:

set $menu eval "$(dot-desktop "$(dot-desktop | wldash start-or-kill)")"
bindsym --release Super_L exec $menu

However, Super_L is also my $mod key.

set $mod Mod4

The above exec $menu does not spawn wldash when I'm using combinations like $mod+j. The issue is that it does spawn it if I initiate a drag or resize operation using mouse.

My guess is that the $mod gets consumed when pressed in combination with a key on a keyboard, but does not when a mouse button is used instead, leading to erroneous triggering of the launcher in my example.

I have used wldash purely as an example above. Same behavior can be observed using any other software (bemenu, krunner, albert to name a few that I've tried).

I'd like to propose the $mod+mouse interaction be made equivalent to $mod+key.

[eternal-sorrow]

set $menu eval "$(dot-desktop "$(dot-desktop | wldash start-or-kill)")"

aren't the nested quotes a problem here?

[Mel34]

No, author of wldash integrated dot-desktop into wldash, so in it's latest iteration my $menu looks very simple: set $menu wldash. And please don't get stuck on wldash, as stated it was used only as an example.

[icasdri]

I would also like to bind the "super key" to a "launcher" program, but this issue makes using bindsym --release Super_L less than ideal.

Example (hopefully this can clarify the current behavior)

# desired "super key" to "launcher" binding
bindsym --release Super_L exec launcher.sh

# example keyboard binding
bindsym Mod4+Return exec example_keyboard_cmd.sh

# example mouse binding
bindsym Mod4+button1 exec example_mouse_cmd.sh

# floating modifier (sort of like a mouse binding)
floating_modifier Mod4

Current behavior

• Pressing and releasing Super_L on it's own executes launcher.sh ✅
• Pressing the combination Super_L+Return executes example_keyboard_cmd.sh ✅ and does NOT execute launcher.sh ✅
• Pressing the combination Super_L+mouse button 1 (on a window title bar to trigger the mouse binding) executes example_mouse_cmd.sh ✅ but also executes launcher.sh :x:
• Pressing and holding Super_L then using the mouse to drag a window (either floating or tiled) causes the window to move (if floating) or re-tile (if tiled) (i.e. correct floating_modifier behavior) ✅ but then afterward also executes launcher.sh :x:

Expected behavior

If Super_L has already been interpreted as a modifier (Mod4) for a keyboard binding, mouse binding, or floating_modifier action, then bindsym --release Super_L ... should not trigger when that Super_L is subsequently released. This is already true for keyboard bindings 😀 but not for mouse bindings or floating_modifier actions 😢.

Sidenote

This behavior of using Super_L to execute a "launcher" program can be accomplished under X (e.g. i3) with xcape by binding the "launcher" program to a "normal" keybinding and handling Super_L with xcape, e.g.

bindsym Mod1+F2 exec launcher.sh
exec xcape -e 'Super_L=Alt_L|F2'

This makes #719 related.