Mouse support improve

[donob4n]

After some months (years?) without using a mouse I started to use one again and noticed some minor usability problems with bemenu which could be easily improved. The main problem is that you can't do anything without moving the cursor to the bemenu region, which on pretty big screens is horrible for productivity.

Mi idea would be that 'bemenu' captures the mouse input (the same that it does with the keyboard) so you can highligh the desired item using the scroll. Once your desired option is selected just left-click (same as presisng Enter) and wolà, you handle the bemenu decision with the right-hand without need to moving the cursor one mile away. A right click could be interpreted as Esc key.

Before doing it as a weird workaround I would like to hear opinions and check if it could be accepted upstream.

[Cloudef]

I think the mouse support for bemenu was originally made for phone devices. @stacyharper is probably the right person to talk to!

[stacyharper]

Bemenu is useable with or without mouse on Wayland. Even if you never enter the surface with your pointer, bemenu should behave exactly the same way with the keyboard.

The current behavior is that you highlight the entry when moving the pointer, select with a click, and change the page with scroll. This behavior is similar to the one on touch screens, on mobile devices principally.

About your recommendation, it is impossible to do so on Wayland. We only receive events for pointer movements while it is inside the Bemenu surface (or on held clicks or touches).

[stacyharper]

Some clues if someone wanna tackle on this:

There is the relative-pointer-unstable-v1 protocol that could help implementing this mode. I'm not sure yet how it would behave with a layer-shell, if we could start receiving events as soon as the menu pop. Or if we would need a hack to start receiving events.

We could also maybe use xdg-popup, or a larger (mostly transparent) surface, to grab the pointer events outside of the drawed on surface. We could then probably map the surface and the events coordinate from the backend. Then it become also possible to implement this kind of behaviors.

But this behavior would be imo harder to use for some user. We then can't predict the entry position, to browse menus fast. I'm not strongly against, but I think I prefer the current behavior (that I defined so..).