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
Mike Blumenkrantz
Carsten Haitzler