we're pointer playing anyway so types here are not really useful. we
have to get our ptrs right - including alignment, and these warnings
are not useful and just noise.
this clears up soem warnings and do the cast on providing the pointer
to ecore_x_window_prop_property_get() which since it has to allocate
the data will be fine for alignment anyway, so a void * cast will do.
so we cast a lot of ptrs to other types as that is then the actual
type of the object. all these objects are allocated by malloc nad
friends so this is ok. but gcc on arm is not happy and warns. maybe it
assume this ptr could be to an element in an array of structs of this
type and so on thus will have specific alignment enforced by compiler
but our casting may disturb it? anyway. cast via void first fixes it.
we can focus on other real warnings and errors instead.
gcc on arm is actually validly complaining about us using int * ptrs
to point to char * data and thus it likely be unaligned, so work in
reverse. make the data int * aligned and when needed mess with it as
char * data byte by byte. warnings gone.
manually initializing this meant it needed to be kept in sync with the
header, something that I'm unlikely to check every time client hooks are
added/removed
xwl clients will attempt to unset the cursor when mousing out of the surface,
but this can happen after evas events are triggered for the ssd due to
latency
if the given surface has mouse.in set, but the mouse is not inside the surface
area, assume that the mouse has just entered the compositor canvas
#TheDisappointer
this avoids conflicts with efl internals, which will break entirely
when DISPLAY is set under wayland, and xwayland internals, which will
abort immediately when efl tries to connect to it during its init phase
in the case where clients are deleted during the same loop that they are
added to an exe_inst, the client will be destroyed before the instance's
delete event returns
ref T4963
in case eina_init uses env vars, move it to befor setuid() so it can
detect. you normally would setuid only for a limited op and we do it
for "the rest of the running" as e_sys is fairly simple.
so on 1 intel laptop and my rpi i'm seeing 100% cpu usage in wayland
mode. it seems something is resizing to 0x0 and then causing a size
change which causes a property change which causes... another request
to 0x0 and repeat. dont set tyhe size changed flags if size actually
didnt change and this fixes that.
This seems like just some copy/paste that was never corrected, however
when calculating coordinate adjustments we should be using the proper
values here. Previous code was using e_comp_canvas_x_root_adjust for
the Y value. This patch uses e_comp_canvas_y_root_adjust for Y
coordinates.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
segv if u go do make installs that install desktop files causing
efreet to recheck desktop files causing e to reset desktop files
causing ibar to refill icons but this causea a segv if a hover menu of
windows for that icon are up at the same time. this fixes that.
@fix
Carsten Haitzler
Mike Blumenkrantz
Derek Foreman
Simon Lees
Chris Michael
Stephen 'Okra' Houston