wew blocks mouse1 when the mask XCB_EVENT_BUTTON_PRESS about opt HOT 8 CLOSED

#3 seems similar to this issue.

from opt.

If you ask wew(1) to grab the pointer, it will.
Grabing the pointer means that the "click" event will be captured by the application, and unfortunately, only one application can register the XCB_EVENT_BUTTON_PRESS per window. To be able to catch it everywhere, wew has to register it on the root window, which has higher precedence over all other windows.

So yeah, it is an expected behavior. What are you trying to achieve? Maybe there is another way to sort this out.

from opt.

One use-case for this would probably be to focus the window when you click on it (for the people out there that use wmutils to script together their own wm).

from opt.

I've never been fond of "click-to-focus" behaviors, which is why I didn't even notice it was impossible to have with wew. I'll check if it is possible to implement, and how to do it then.

from opt.

@z3bratabs but you said my focus_switch script was cool! ;-; j/k

from opt.

I guess it's possible if you combine wew enter/leave events (with fixed inter-window enter/leaves, see #3) with sxhkd and some tmp file that holds the window the mouse is currently in. I'll test this once I get home.

Especially since that would probably count as a "hotkey" and would more likely fit better into the scope if sxhkd than wew, and use wew just to get the neccessary info.

from opt.

It doesn't grab the cursor all the time, only when you explicitely ask for it.

À dim. août 9 01:49:26 2015 GMT+0200, Eduardo Lavaque a écrit :

@z3bratabs but you said my focus_switch script was cool! ;-;

---

Reply to this email directly or view it on GitHub:
#4 (comment)

Envoyé depuis mon Jolla

from opt.

Was trying to make click to focus because sometimes tooltips disappearing would change the foccused window, didn't know it was supposed to grab the mouse.

from opt.