Under wayland evas will sometimes use the old one, I have no idea why.
Fixes a crash bug when mousing out of menus in a GTK app under wayland.
fix T3576
internal wayland windows are windows with ssd, meaning they can only receive
pointer events on the contents of the window and not the entire window including
decoration regions
ref T3819
Wayland argb state depends entirely on the attached buffer, so we
should use that for determining object argb state on wayland.
ref 6d397e313b
ref 60da58d8ad
This test has been pushed into e_comp_object_native_surface_set() and
will be done as appropriate.
Upcoming wayland DMAbuf buffers need native surfaces even if GL isn't
present.
This is supposed to be functionally equivalent, but is a little tricky to
prove.
The benefit of this is a simplification to the callers, which no longer
have to consider gl capabilities in the call, as that is now tested for
internally.
Until now it's been reasonable to consider these together as the
criteria have been similar. With the upcoming introduction of wayland
DMAbuf buffers, they diverge.
We don't need to test for GL in the wayland case because we don't
advertise GL capabilities to clients when we don't support it, so they
can't create GL buffers unless we can display them.
if csd exists in only one of (before || after) a maximize/fullscreen,
this provides info so that the right size can be used when restoring
geometry
...again
in the case where a mouse binding is active and a signal binding is triggered
by the same mouse-up event which also ends the mouse binding, the deferred
nature of edje emissions will result in the signal being received by the
corresponding callback some time after the mouse-up event has been handled by
the client and the mouse binding has ended
to accurately handle these cases, signal bindings triggered in the same event
loop in which a mouse binding has ended after a mouse-up must be rejected in
order to enforce the compositor's mouse grab
fix T3347
an agent object can be used when a client should be represented on the
canvas solely by its window geometry and not including any csd
this creates and manages a mutable object which maintains the same geom
as ec->x/y/w/h and can be operated upon to modify those values
in the case where a client is at 0,0 relative to a zone, changing the coords
in this case will result in the client moving out of the zone by the size of the
csd
In wayland we can be presented with a new frame before being deleted. If
we've never displayed that frame we should (since we released all pointers
to the old frame when we got the new one)
mousing over a window for an x11 client should always yield x11 mouse events
in cases where mouse eventing is required; any events occurring on the comp
object in other cases inside the xwindow region are able to be ignored
this avoids some minor canvas thrashing since the zoomap will try
to reapply existing geometries to the child instead of setting 0 and
triggering infinite callbacks
this case is solely for handling clients which are created with nonzero
position, eg. an x11 window trying to display itself centered upon initial
creation. re_manage indicates a window which is re-managed after a restart of
enlightenment, so these windows clearly do not fall into that case
fixes an issue where windows would move up+left by the size of their frame during
restart
ref 95e133282e
so every time i restart e i have my windows all messed up. it's
INSANELY annoying and time consuming every single time having to move
a dozen or more windows back to where they should be just because i
restarted e. i've narrowed it down to 2 places. 1 which is trying to
handle "out of screen" windows and during startup it seems things are
not quite stable yet as the randr code figures things out until the
event storm settles down.
when this is then fixed - another bit of code just shuffles windows up
all the time by a titlebar whcih is also supremely annoying. this is
the code that adopes a new frame for a window.
so the nasty hack to avoid piles of pain right now is for the first 5
seconds of e's life - don't do this stuff. at least you can now use e
and not be annoyed to hell and back every restart.
yes a nicer fix may be better - but that's going to take a lot more
time and patience and until then - this will do.
in the case where the existence of a zoomap in the comp frame edje has changed
during the course of changing the type, these callbacks must be updated with new
data params in order to ensure accurate operations during callbacks
it's possible for damage to occur before the show interceptor is triggered,
and in this case damages would be lost despite it being a valid usage
ref T3011
there was previously no way to change the type of one of these objects,
meaning that if an object with a dropshadow should no longer have a dropshadow,
it must be re-created
in the case where a new client already has coordinates from creation event,
the frame was never adjusted which resulted in the window being positioned
incorrectly
ref T1106
in the case where a client has no geometry set, attempting to update
the client's geometry during frame recalc will guarantee that wrong
geometry is set, resulting in a bad first frame
there was previously a frame in which maximized x11 csd clients would
reposition themselves offscreen before rendering
this is now fixed by adjusting the client geometries either upon
unsetting the csd or re-setting it, allowing the client to retain its
expected positioning without jitters
when applying new csd to a window which already has csd, the previous
csd must be removed in order to apply any new csd offsets in order to
avoid unwanted moving/resizing
since ICCCM requires that clients be unmapped while iconified, it's necessary
for the compositor to perform one last render prior to the unmap in order to
ensure that mirror objects will still appear as expected. this render must use
the pixmap buffer data in order to avoid timing issues due to async/deferred
rendering, and it is only necessary for the case of clients rendering with a
native surface
fix T2788
in some cases, it's possible for a client which expects to render on
the next frame to actually render on the frame after. in these cases,
the compositor must not clear the pixmap image until after the render
has occurred in order to avoid inaccuracies. for this reason, the best
place to flag a client for post-render work is at the time of the client's
render
ref T2762
ref D3120
if this isn't explicitly blocked by config options then allowing resizes
on the unmaximized axes is necessary in order to avoid accidentally
queuing a full unmaximize
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
Mike Blumenkrantz
Derek Foreman
Carsten Haitzler