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)
Like with all other wayland protocols I add the files generated with wayland
scanner here. Also the xml so we have the source around for updating and
modifications. We might want to think about wayland-scanner support in our build
system but this works for now.
The protocol prototype is hold simple and does only have a uuid signal and provide
call to handle the uuid assignment from compositor to app and app providing its
uuid if present already.
I have been running with this enabled for a while and it should not make
trouble but if it does simply reverting this one if totally fine while I'm
away.
The e_remember infrastructure already hooks into all needed places to keep
a record of the given properties for an e_client. We use this to update the
UUID store.
Signed-off-by: Stefan Schmidt <s.schmidt@samsung.com>
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
these helper functions automatically account for "swapped" xwayland
clients and return the expected value from the wl client comp_data.
in this way, all of the current x11 compositor code can be reused with
minimal changes
in order to maximize the amount of reused code the following details the current
process for xwayland compositing:
* get map request from window
* force reparenting
* show window
* await WL_SURFACE_ID x11 message
* move x11 client data + pixmap onto corresponding wayland client
* business as usual with wayland compositing
this is pretty similar to the method of the reference code in weston,
except that there's no x11 compositor in weston
This is macro 101, you don't EVER put multiple statements in a macro
like that.
See Chris's commits, these broken macros already introduced (subtle)
bugs. Always surround macros in "do {} while()" unless you absolutely
can't (like when you declare a new variable to be used in the scope).
Why is it even there? I think we can safely assume eina log is available
for usage in E...
@fix
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
Mike Blumenkrantz
Stefan Schmidt
Chris Michael
Carsten Haitzler
Tom Hacohen