this is new now - if i alt+left mouse drag an efm window around and i happened to have been over an efm icon when i pressed... when i release the efm icon drags. middle mouse to resize has similar bad effects to the point of stopping all input on an internal e window (efm window or other settings dialogs etc.). normal apps windows dont get the first mouse down. something has broken with filtering out these events to "self clients". (so the down goes through, the up does not leaving the window is an odd state).
- rE90f0740d2751: use parent windows for x11 binding grabs
rEdc0ec2339e67: feed mouse up events to internal wins before mouse out during action exec
rE55c83134c17c: use parent windows for x11 binding grabs
rE20f1aa87272c: feed mouse up events to internal wins before mouse out during action exec
rEd546536c60f2: selectively reject comp object signal emissions based on action_client state
rEbdc8078f876c: feed mouse out to internal clients upon activating a mouse binding
rE39717a8a388d: feed mouse-up events for all buttons on internal wins when activating a binding
rEee1617766009: selectively reject comp object signal emissions based on action_client state
rE609276e12df8: feed mouse out to internal clients upon activating a mouse binding
rE893f3b166944: feed mouse-up events for all buttons on internal wins when activating a binding
hmm no - now it just changed nature... go to e settings and alt+left clikc when mouse is over some menu item there like "wallpaper" or "theme" ... alt+left click and drag.
the client window gets a mouse up event. and "executes" the wallpaper click. alt+left click over close button .. window goes away. the fake mouse up is now just a different badness. :)
back open... but now instead of dnding the icon it just begins a drag-box-select even though mouse is no longer down, blue select box gets dragged around wherever the mouse goes eg in the efm window.
it's back. but now alt+left click on an efm widnow selects the icon - it shouldn't. window shouldn't even see the click. it's trapped by e. this also then results in alt+left click drag window around eg the control panel window, then if your mouse was over an item in the control panel, then that item gets selected and the dialog comes up.
There's really not a good solution to this. Internal windows use the same event that the compositor uses, and under X11 the propagation is such that internal windows receive the event before the compositor since the engine directly receives X11 mouse input.
The best I can do off the top of my head would be to add hacks to call ecore_event_evas_shutdown() until it's dead, then start it up the same number of times in order to change the callback ordering, but this seems like it could cause issues if another compositor-side handler decides not to propagate the event before the window receives it.
this USED to work because in x11 we used passive grabs where xserver redirected then event before it got to the window. we had the passive grab on a parent window of the client win (x grab button). you have changed all of the event flow thus breaking this and creating the problem you now have. :) you can go back to using passive grabs in x11 and thus window id will be a parent window not the client thus it wont be processed as an event for the client window even within the same process. for wayland you'll have to sort it out some other way. likely when you trap events on the image obj - dont send on to client if they match a binding button entry - just like passive grabs do in x11.
Ah, okay, so this was just the result of using the client window instead of the parent window for binding grabs.
Wayland has no issues with this since the compositor handles eventing correctly.
see simple! :) was correct before with parent window with grab. thats why we checked parent and client window id for matching window id's to a border... for things like passive grabs. :)