i found e spinning at 100% just with 1 windows in wayland... open 2
terminology wins and move mouse form one to the other... 100% cpu. e
was moving seemingly a cursor client window? to the same coord again
and again as it was hidden...
this fixes that. no more spinning cpu
cfg files were installed on top of eachother in the wrong directories
and they were unreadable by anyone but root (if you sudo make
install)... so fix this with my new chmod fixing stuff (yes meson
doesnt let you specific permissions for custom targets).
also... there isn't realy a need to track the screensaver state...
powersave sleep will drop back to an hour between sleeps if we're in
freeze mode (it could be longer or even be indefinite). it will be
woken up if powersave state changes...
We stop allowing client updates when the screensaver is on to save power,
however this happens at the start of the fade-out. On wayland this stops
any visible client change.
If we wait until after the canvas is set to manual render instead then
we get similar benefit but don't lose display updates while they're
This reverts commit ee71ea63ec.
Revert "reduce include deps for enlightenment_thumb binary"
This reverts commit cce14fa839.
both of these i reverted.... because they both CHANGE the define of
and this is wrong. e.h defines this so that these symbols are exposed.
E_API, EAPI and friends are desighned to explicitly expose symbols.
because if you try and make STRICTER binaries that only have symbols
for what was EXPLICTLY exposed like the CFLAG -fvisibility=hidden ...
then any api not explicitly marked with the attribute of visible which
that E_API macro is intended for... will be invisible. it will not
exist. this means a whole MOUNTAIN of modules stop loading as they
can't find these symbols. E_API isn't just source sugar tagging. it's
actually functional. i'd suggest using -fvisibility=hidden in your
CFLAGS by default. it's also not always portable between all compilers
so beware... (it was introduced years ago in gcc... i think clang
offers it. i don't know about icc or any others).
so since E_API is defined in e.h ... we may as well keep the e.h
include there instead of hand re-writing a list of includes. does
reducing the include deps really have an impact worth talking about on
compile time? the commit logs didn't say. but it does break module
loading and does it by adding lots of lines of code that are far mroe
easily broken now (this is an examplt). :)