according to ICCCM 4.1.4:
Only the client can effect a transition into or out of the Withdrawn state
withdrawn windows cannot be shown under any circumstances. the best that can
be done is to try mapping the window and hope it decides to appear.
to prevent any inadvertent showing of the window before it leaves the
withdrawn state, we play games with the E_Client->ignored flag in order
to skip client evals until we get notified that maybe we want to stop
skipping those evals
ref T2745
also includes 0e3cc2f533
gtk apps set an atom which provides information about the area
where non-window content (eg. shadows) may be drawn; this area
must not be used in placement calculations.
the easiest method for implementing this functionality was to add
a case to the compositor geometry interceptors which effectively
flip the client struct geometry values such that the E_Client->client
is outside of the more commonly used E_Client->x/y/w/h
fix T2744
it seems that since the first version of the enlightenment compositor
in e17, damage events in x11 have never been used correctly. using
the event struct members will only give the bounding box/area instead
of the damaged regions; the real regions must be explicitly fetched
from the server
this removes the need for a lot of hacks which were added over the years
to make override windows render correctly, and also probably reduces
rendering overhead slightly
in the case that the canvas window has just had focus set on it, apply this focus
and ensure that no client retains focus
this resolves a race condition where focusing the compositor canvas <-> client
extremely quickly would result in a client trying to steal focus when it was
not actually focused
a notable (but trivial) side effect is that now when flipping desks at high speed while using
mouse-based focus policies, the user is almost guaranteed to end on a desk which
has open windows on it
it seems that the reported damage events upon resizing an override window
are not accurate, and so we must force a full damage here while avoiding a
render queue in order to ensure that the full contents of the override will
be rendered in the next frame
fix T2045
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
canvas grabs changed completely in 1.15, and so it's required that
x11 grab handling also have special runtime cases for this
for such versions the compositor must:
* always grab the internal client window instead of the parent
* always ungrab the window when it has focus
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
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
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
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)
this came in a patch that I take full responsibility for not adequately reviewing at the time.
the names are confusing and counterintuitive, and it does not properly include the client namespace.
backported to avoid future backport conflicts
the problem is something changes window gravity... what i don't know,
but hey - just forcibly move window to 0,0 which is where we expect it
anyway when resizing.
@fix
according to the shape extension protocol, the number of rectangles returned should be checked to determine a client's shape. if 0 is returned, the client has no shape, meaning that it either should not be drawn or should have no input region. this improves behavior with various client window types such as tooltips
ref T1820
Mike Blumenkrantz
Carsten Haitzler
Chris Michael