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
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
the dialog for now is simple and lets you just raw edit the properties
per screen in a dialog. nothing fancy. not user firendly. but it works.
the randr core has been totally rewritten and tested against a range
of drivers and setups before even getting a commit. it works solidly
and configures screens reliably now. drivers tested:
nvidia
intel
radeon
some drivers still are unreliable in terms of delivering plug/unplug
events for outputs (both intel and radeon are flakey - nvidia is solid
and reliable). so to fix this there is now a screen redo action you
can bind to a hotkey or something and have e re-evaluate current
screen setup and apply ny pending config if needed.
also to make reconfiguring prettier the screen is faded to black
first, then configured, then faded back in. some drivers work
flawlessly with this, others still flicker some garbage.
i admit - i haven't tested nouveau, but my general take on this is the
randr code is now in far better shape than where it was (minus pretty
and easy dialog). the dialog can be done next, but i'd like to get the
core in now for more testing.
@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
this was a neat experiment, but apparently it's not going to be usable for a long time in anything outside efl/elm
This reverts commits f87b9900fa, a49cede790, 81038f8d02, 47cfb31752.
Summary:
it fixes crash when running wl client apps on e wayland server.
invalid comp object pointer value is returned by using eo_data_scope_get.
thus eo_isa should be added before eo_data_scope_get.
Test Plan:
1. run e wl server
2. run wl client terminlogy
3. run second wl client elementary_test
Reviewers: raster, devilhorns, zmike, stefan_schmidt
CC: cedric
Differential Revision: https://phab.enlightenment.org/D919
Mike Blumenkrantz
Derek Foreman
Carsten Haitzler
Yomi
Chris Michael
Vincent Torri
Mike Blumenkrantz
Cedric BAIL
Tom Hacohen
Gwanglim Lee
Seunghun Lee