this used to be set on show since the assumption was that show was the
first time the client would be seen, but this turns out to be incorrect
and results in focus being set too early (breaking policy)
improve mixer volume display in titlebar now to show a unified
display. average volume of all non-muted sinks for volume display and
if at least 1 sink is non-muted display as not muted as some sound is
coming from that app... somwhere...
when resume is called we are just notifing the theme that e is back
there. There is no E_Sys_Action for it, so its enough for now to just
call the backlight to fade back in and emit the signal to the theme.
This should fix e blocking sys actions
so add a new sink or get an update on state and e will SEt volume/mute
settings, not just passively disdplay them. this has been messing up
rage's winlist (mouse over on right) for several months now... and e
is/was wrong.
this doesnt fix all. if an app has multiple streams really this client
mixer needs to display a control per stream, not a single one - eg in
a popup. in fact volume shoud likely be done in a popup instead of
inside titlebar anyway :)
but this fixes the most annoying problem where withotu users doing
anything, the audio starts to play from streams explicitly muted by
the app...
warning found a bug - filling in chr fileds with an api that expects
ptrs to ints - this is doing really bad things like unaligned writes
and it's overiting adjacent memory. fix
we did cast to Evas_Native_Surface * but this just causes warnings due
to the input ptr being char * from memcup. as this will be aligned due
to allocation, we're ok, so use a void * cast instead
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.
this is a remnant from xdg5-only code where new_client meant "first buffer". with
xdg6, this is no longer the case since a surface can receive infinite commits
without ever having a buffer attached
ref 9a82f7bcb0
xdg6 allows for clients without buffers to be configured such that the
first buffer will match the configured state
if a client is sized before this point, the changes.size flag will be set
UNIGNORE is the hook to watch for wl clients as they are added; the
ignore mechanism prevents most of the compositor from processing
clients. this is a stupid method from an api perspective since it's
different in x11 and wl, so it should probably be improved on in the future
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
This reverts commit e1c3120689.
this commit revealed a number of issues with the xdg6 implementation related
to unconfigured buffer management: see subsequent patches for a less
sledgehammer-y solution
ref 5497fadce4
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
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
this is an easy format string attack vector which serves no purpose
that I can fathom. the commit log where it was added it also made
no mention of this, as it was done in a seemingly-unrelated feature
addition
let's say you sue tiling or some module and it wants a window by
default to maximize or fill the screen or be size XxY ... this stops
the client first having a buffer smaller (or larger) and then sizing
down rendering 2 times (one of the renders is pointless). this makes
initial buffer render/show seamless as it should be in wayland.
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 yeah, I've literally used sed to replace every occurrence of
ecore_time_add() with ecore_timer_loop_add() because I'm reasonably
confident that no part of E has a legitimate need for timer based on the
exact current time.
It would be really nice if I'm not wrong. :)
The reason for this is the incredible spew of clock_gettime() calls I'm
seeing on an ARM system (that should have a vdso for gettime, but...)
This can amount to thousands of system calls per second.
#YOLO
this shortens logout timeout for "apps still hanging around" to 3
seconds meaning that within 3 seconds something should complain that
logout is taking too long so you know your logout request actually
went through... and any app not responding in 3 seconds is likely
"bad" (swapped out, hung on blocking i/o or something or doing a "are
you sure" dialog thing).
keys of pointer hashes are represent as void** so you just get a pointer
to where the pointer can be found. This now dereferences the pointer so
the correct value is used.
This fixes T5136.
this should keep the perfromance of the prior commit
f80f73a7c9 and now get quality back by
generating thumbnails at higher resolution then scaling down from there.
@fix
bgp[review uses livethumb. livethumb by definition uses an image
canvas with a sw engine and thus not only renders the bg with another
engine, it also is causing continual texture uploads thanks to the
pager and this shows clearly on slow systems. this causes memory
duplication for the same wallpaper as ever bg has its own canvas and
buffer etc.
this does come with a quality drop though and that's up for debate. we
COULD use something else like a proxy or map in between to force a
higher "virtual" res vs output. but for now at least this solves both
a memory bloat issue and a performance problem.
@fix
Mike Blumenkrantz
Michael Bouchaud
Carsten Haitzler
Stephen 'Okra' Houston
Marcel Hollerbach
Chris Michael
Derek Foreman