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
when working with Extremely Serious effects, it may be the case that
a user is rendering at such an advanced level that any attempt by
enlightenment to perform rendering will be like a child trying to
reproduce a masterpiece of art while using fingerpaints
https://www.youtube.com/watch?v=tY6qag5KFx0&hd=1
it's a pretty trivial thing to hand-composite a client, so this will
allow someone to do something like render out a gaussian blur to an fbo
using a client's texture and then render the fbo onto the compositor
canvas with minimal overhead
it's impossible to determine this at the time of calling without adding
some sort of callback here; edje signals are deferred, meaning that
an interested user will not be able to check the state of a client
when it begins to hide
when a client is set to "Always on Top", it will be on the same layer
as override clients. this can cause strange stacking and mouse eventing
in cases where these windows occupy the same space and the normal client
is stacked over the override
in the case of recursive desk flips, toggling a desk's visibility may
erroneously send queued evas events to the client's frame object, leading
to a focus-set (mouse-based focus models) which triggers a desk flip
inside the original desk flip. this "inner" desk flip is spurious and
should be ignored
based on testing, this breaks all rendering of related objects. I
suspect that the image border needs to be manually scaled based on
image::mirror proportions in order for this to work as expected, but
adding the required code seems like too much complexity for nearly zero
gain
under wayland, some surfaces (eg. cursors) would attempt to show prior to
having acquired their actual size. these show attempts should be rejected
until the size has been set to ensure that rendering can proceed as expected
fix T2557
this is more of an academic case than any existing scenario, but
it's possible that an effect may be stopped by something attempting
to trigger another effect during the animation
previously the animating flag would receive an additional increment for
every effect, even if it was currently animating a prior effect, leading
to objects which were never deleted
this allows improvements to the code which provides hide animations,
allowing clients to begin hiding during their show animations instead
of rendering a black rectangle
this follows 56cabf59c6 then
4e5521b4d8 where i have been trying to
fix a crash with e client and comp win references etc. i have gone
over all referencing with a fine tooth comb and found all the nigglies
i can., no leaks now, no crashes, no valgrind complaints etc. so i
call this fixed now. as best i know this is new in e20, so not a
backport fix
refs were inconsistent - thus this fixed the fullscreen quit bug by
never freeing a client. this brings the bug back by fixing this client
leak. i'll look again at this later.
the refcoutning for e_comp and e comp clients seemed to be a bit off -
i read over every ref and unref carefully and fix it. this leads to
the com-_data being null (properly now), so now check for that too.
these are specific types of animation for use when toggling window visibility.
they combine with existing compositor window animations to provide nicer integration
for very specific types of windows
see https://www.youtube.com/watch?v=hIVdd0Z2K00 for a demo