Mouse left click does not work

[salastro]

When I left-click on an item (motion patch enabled) it does nothing. I tried without motion patch and it still did not work. However, clicks on the prompt does clear it as expected.

I tried https://github.com/sbstnc/dmenu-ee and it does work (selects the item).

[bakkeby]

Clearly you would be using the mouse support patch as well. There is not that much to that patch so there must be something that is interfering if mouse clicks does not work.

I can't reproduce this issue in my testing. Perhaps provide your config.h and patches.h?

[cpelley]

I'm having similar difficulty. I tried disabling all patches besides the mouse support + hover ones. See below:

c34ae7d9d59d3b4cf7bc7ab051e6a580596c3a60

$ git diff
diff --git a/config.mk b/config.mk
index 9d94f27..762f847 100644
--- a/config.mk
+++ b/config.mk
@@ -2,7 +2,7 @@
 VERSION = 5.3
 
 # paths
-PREFIX = /usr/local
+PREFIX = $(HOME)/.local
 MANPREFIX = $(PREFIX)/share/man
 
 X11INC = /usr/X11R6/include

$ git diff --no-index patches.def.h patches.h
diff --git a/patches.def.h b/patches.h
index d3076bf..5bff6a4 100644
--- a/patches.def.h
+++ b/patches.h
@@ -144,12 +144,12 @@
 /* This patch adds basic mouse support for dmenu.
  * https://tools.suckless.org/dmenu/patches/mouse-support/
  */
-#define MOUSE_SUPPORT_PATCH 0
+#define MOUSE_SUPPORT_PATCH 1
 
 /* Expands the above to support mouse hovering.
  * https://tools.suckless.org/dmenu/patches/mouse-support/
  */
-#define MOTION_SUPPORT_PATCH 0
+#define MOTION_SUPPORT_PATCH 1
 
 /* Without this patch when you press Ctrl+Enter dmenu just outputs current item and it is not
  * possible to undo that.

Interesting that this works at your end mind.

Any thoughts?? thank you in advance 👍 If still working at your end, perhaps this issue is sensitive to system setup.

[bakkeby]

A few things that you may check.

1. Are you using any GTK scaling?

Asking because that can screw with the reported mouse coordinates in the events, but I have only seen that in the context of dwm.

2. Have you made any changes to mouse input via xinput?

3. When hovering items, using the motion support patch, does it highlight the menu item under the mouse cursor?

[cpelley]

Are you using any GTK scaling?

I don't think so, I'm using a gnome azure VDI and I don't think it has any option for fractional scaling (I'm not overly familiar with gnome mind).

Have you made any changes to mouse input via xinput?

I haven't myself and I doubt this would be the case with the VDI.

When hovering items, using the motion support patch, does it highlight the menu item under the mouse cursor?

It does. So I guess that would seem to indicate the the mouse coordinates are being read correctly. I would have said, that perhaps the first mouse button is being hijacked by something else, but adding printf statements does seem to indicate that it is being registered 🤷‍♂

Thanks for your reply, really appreciated ❤

[tsukishimashijima]

I built dmenu with mouse patch, seems like I have the same issue. However, by using an alternative window manager, the issue isn't there.

As weird as it seems, I suspect that there's a dwm patch interfering with the mouse clicks. I will look further into this.

Edit: I was wrong. Apparently, if I run dwm without sourcing my xinitrc, the left clicks work. I'll see what's causing this.

[tsukishimashijima]

Okay, this is getting weird. Apparently, this issue is caused only if numlock is on. @bakkeby can you reproduce this?

[bakkeby]

Ah right having the numlock on would cause the left mouse click not to work.

Incidentally I did address this issue in my own build of dmenu. I believe the original issue I was looking into had to do with text input and enabling/disabling num-lock depending on whether it was on or not prior to starting dmenu.

https://github.com/bakkeby/dmenu/compare/2b4c1c83f2d322df7450f8262c37642a0802fa87...f341cae3c9bacbed135bd47c720e1de0cbd93301

I should be able to port that to dmenu-flexipatch. If need be I can also create a standalone patch.

[tsukishimashijima]

Awesome, thanks for your help!

[bakkeby]

Looking closer I find that looking up what modifier is used for the num-lock is not actually necessary in this case. The blocker was an if statement that would prevent clicks from evaluating if any modifier other than Ctrl was used, which is always the case when num-lock is enabled.

-	if (ev->state & ~ControlMask)
+	if (ev->state & ShiftMask)
 		return;

The if statement itself is not particularly important; I think that it is mainly to mimic the behaviour when you type and hit enter with modifiers. It can probably be removed in full, but I left a block when holding down the Shift modifier as that is associated with returning the typed input text (when hitting Shift+enter) rather than the selected item - which does not apply in the context of mouse support.

Let me know if you have any issues with this.

[cpelley]

Fantastic! I can confirm that everything works fine for me now 😄 Thank you both for looking into this and resolving ❤

[tsukishimashijima]

fixed, this issue can safely be closed

[bakkeby]

Very good, I'll mark this as closed. Thanks for the help debugging.