these are triggered "in passing" when mouse in events occur and do
not necessarily indicate that the mouse has entered this specific window
failing to reject such events can cause mouse-based focus policies to
attempt to set focus onto windows which are not visible, resulting in
an infinite loop where no window is actually focused
in the event that these windows are different, event_window is the parent of window
which may or may not be explicitly tracked by an E_Client, so the wheel events here
should be sent to the parent as is done in mouse button events
fix T2604
it seems that some clients, eg. libreoffice, don't set the modal window
property on child dialogs. instead of fighting for focus, set up the child
as a modal on the parent and then avoid the whole issue
fix T2594
a client with this flag set here is unreliable to use as a stacking
reference since it has yet to be stacked and can be located anywhere
in the window stack.
fixes internal window stacking on startup
blocks execution of resizes until the surface commit arrives. reduces
the race condition between resize and render and eliminates frame drops
during slow resizes
xwayland compositing requires that we set up a root window cursor image
immediately since we'll be getting that cursor surface to display as soon
as the pointer goes out of an x11 client's window
this requires that both canvas cursors and window cursors be present for the same
E_Pointer object, even though only the canvas cursor is actually visible
#kansas
due to recent changes in ecore-input-evas, mouse events are propagated
differently; specifically, there are now "more" events than there previously were.
as a result, grabs on internal wins are no longer necessary, though they probably
never were necessary after the elm conversion
see 5cb6cdbc5e1a13ea0262e155983b494e6519abde in efl
I did an audit of this and it seemed that it no longer served the purpose
for which it was originally intended. specifically, this is for enforcing
click: raise/focus options, and so grabs must be in play on client windows
only when they are not focused to ensure that we get mouse events and can
then focus them. the grabs must then be removed once the window has focus
to avoid spurious mouse eventing
xwayland sets a wrong size on some (eg. menus) clients and wayland
cannot provide geometry or stacking information, so ensure that all
of this is copied over
also remove overrides from focus stack
this should fix the case of mouse-based focus policies trying to reapply
focus after another client has stolen it away without the pointer leaving
the window
in the case of different window <-> event_window, window is a child window
of event_window, and thus checking event_window here is valid (and necessary)
when you have click to focus we have a passive grab set up. somewhere
that window changed to the parent window instead of the client. this
leads to a side effect of a leave and enter event on clients for every
click. generally clients are ok with this, but some seem to have buggy
event handling. these enter/leave events are a side effect of the
passive grab even though we allow/replay the event.
this fixes that by placing passive grabs on the client window itself
instead of the parent.
@fix
these helper functions automatically account for "swapped" xwayland
clients and return the expected value from the wl client comp_data.
in this way, all of the current x11 compositor code can be reused with
minimal changes
in order to maximize the amount of reused code the following details the current
process for xwayland compositing:
* get map request from window
* force reparenting
* show window
* await WL_SURFACE_ID x11 message
* move x11 client data + pixmap onto corresponding wayland client
* business as usual with wayland compositing
this is pretty similar to the method of the reference code in weston,
except that there's no x11 compositor in weston
Mike Blumenkrantz
Carsten Haitzler