On Wed, 16 Dec 2020 11:23:41 +0100 Quelrond <quelr...@gmail.com> said:
> Hi! > > On 16/12/2020 11:07, Carsten Haitzler wrote: > > On Wed, 16 Dec 2020 10:12:03 +0100 Quelrond <quelr...@gmail.com> said: > > > >> Hello, > >> > >> I use Enlightenment 0.24.2 and EFL 1.25.1 on FreeBSD 12.1. I have a > >> mouse with additional buttons (wheel-left and wheel-right). I bound > >> these buttons in Enlightenment to Window:List->Next Window and > >> Window:List->Previous Window. I have two mappings for every button - for > >> 'Any' context and for 'Window' context. > >> > >> The mappings work correctly - I have WinList popup shown and I can > >> switch windows like this. The problem is that starting from one update > >> (E or EFL or GTK or QT ot something else) these mappings are propagated > >> to the windows under mouse pointer (even not to the currently focused > >> one). So, these events are ALSO processed by applications, active in > >> these windows. For example, if I click 'wheel-right' - I have WinList > >> popup shown AND the editor under cursor scrolls right. I don't want it. > >> I don't want that the mouse events processed by Enlightenment would be > >> propagated to underlying windows. How can I block it? > > run xev. put out mouse over xev. press those buttons. you should NOT get > > button press events. > > > > i bet the apps are bypassing regular x events and going right to xinput and > > listening to the xinput device directly thus bypassing the regular x event > > pipeline... test with xev above. > > The xev sees the following when I press 'wheel-right' inside his window: > > > LeaveNotify event, serial 39, synthetic NO, window 0x6200001, > root 0x2a2, subw 0x0, time 9369671, (93,63), root:(3088,499), > mode NotifyGrab, detail NotifyAncestor, same_screen YES, > focus YES, state 16 > > EnterNotify event, serial 39, synthetic NO, window 0x6200001, > root 0x2a2, subw 0x0, time 9369671, (93,63), root:(3088,499), > mode NotifyUngrab, detail NotifyAncestor, same_screen YES, > focus YES, state 16 > > KeymapNotify event, serial 39, synthetic NO, window 0x0, > keys: 4294967202 0 0 0 0 0 0 0 0 0 0 0 0 0 > 0 0 > 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 > > LeaveNotify event, serial 39, synthetic NO, window 0x6200001, > root 0x2a2, subw 0x0, time 9369672, (93,63), root:(3088,499), > mode NotifyGrab, detail NotifyNonlinear, same_screen YES, > focus YES, state 16 > > FocusOut event, serial 39, synthetic NO, window 0x6200001, > mode NotifyGrab, detail NotifyNonlinear > > FocusIn event, serial 39, synthetic NO, window 0x6200001, > mode NotifyUngrab, detail NotifyNonlinear > > KeymapNotify event, serial 39, synthetic NO, window 0x0, > keys: 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 > > FocusOut event, serial 39, synthetic NO, window 0x6200001, > mode NotifyNormal, detail NotifyNonlinear so it's not seeing the button presses. those events are a side-effect of the passive button grabs e has. so ... you will hate this. it's not a problem with e. it's the app/toolkit that is bypassing the regular input pipeline and going directly to the xinput device and listening to it directly no matter what. the xinput extensions allows this. you would find almost all wm's would be affected by this (or anything that grabs buttons passively for bindings as has been the case in x for 30 years). they are bypassing this flow and NOT respecting having lost focus due to a grab. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- Carsten Haitzler - ras...@rasterman.com _______________________________________________ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
