| Issue 175: | Click on unfocused window eaten | |
| 2 people starred this issue and may be notified of changes. | Back to list |
If I click on an unfocused window, it gets focused, but the click is eaten by xmonad. It would be nice to have a way to configure it in a way the click would go to the window too (both focus & click sent to the app). I'm using xmonad 0.7 Thank you |
|
,
Apr 29, 2008
The current behavior is intentional. This modification may be possible as a contrib module.
Status: WontFix
|
|
,
Apr 29, 2008
I know it's intentional, this should have been a wish, not defect, but this google Bugzilla thing does not seem to offer me the choice. Is it possible to reopen it and set it on your side? (Maybe I should write on some google support). Thanks |
|
,
Apr 30, 2008
I agree that this is a valid wishlist bug, so I’m tagging it as such.
Status: Accepted
Cc: nomeata Labels: -Type-Defect Type-Enhancement |
|
,
May 01, 2008
(No comment was entered for this change.)
Labels: -Priority-Medium Priority-Low
|
|
,
Nov 15, 2009
Anybody know if this is possible? I'm gona try looking around but my Haskell knowledge is quite basic so I'm not expecting much. |
|
,
Nov 20, 2009
Well done a lot of fiddling and learning about how this all works.
handle e@(ButtonEvent {ev_window = w,ev_event_type = t,ev_button = b })
gets called every time you click on an unfocused window or click while holding down
modifiers for a mouse binding. I found grabButtons which explains the mouse binding
calls, but I can't figure out why specifically clicking on an unfocused window calls
it. I assume thats just built in to xlib though.
Going to try sending an button press event to the hovered window to see if that'll work.
|
|
,
Nov 20, 2009
Actually I guess that won't work as XSendEvent will send a synthetic event which will probably get ignored. Maybe XPutBackEvent but if I can't figure out why only clicks on unfocused windows get grabbed then when the event is ran again xmonad would just eat it again. |
|
|
|