so some apps/clients mess with screensaver/blanking/dpms behind e's
back. work around this - every 10 sec poll and check (ugly) and if
things are nto set as they should be ... force them to be set that
way. may lead to fights over this but too many people complaining
about steam or other apps messing with this.
For some reason I have yet to divine we don't get an initial unmap
event due to the reparent of the energyxt dialog windows and the
"ignore that first unmap" flag does not get cleared because it doesn't
happen. later when the dialog is withdrawn {9unmapped) this is ignored
then when you close the dialog... thus keeping it around as far as e
is concerned.
so to fix this - add a small timeout to clean this flag after a
show/map.
@fix
assume it went to 0 size if removed and already a csd frame window
which is what chomium does going fullscreen - i didnt see this as i
used chromium with system titlebars not its own.
@fix
also getrlimit to know if we can lower nice level, you will want
something like:
* - nice 0
in /etc/security/limits.conf to allow for users to both raise and
lower nice level up until this limit (ie not negative nice levels).
perhaps enlightenment_system needs to do this...
we get a spurious mouse out if your window is small then told to go
fullscreen which then causes in ponter focus a unfocus event which
causes e to restore window to its non-fulscreen mode which then may
cause a mouse in again if mouse is positioned right which causes a "go
fullscreen now again" and so on... fix this and ignore that mouse out
right after going fullscreen.
@fix
as per icccm - client should remove WM_STATE when withdrawing... and
qt relies on WM_STATE to know if it re-show a window - the property
it itself refused to remove...
e didn't set shape rects for input overflow areas for the resize
handles in theme to work on top of other clients and client areas.
this should make that all work now and make the resize handle area
bigger than it actually looks.
@fix
This was a nice idea to fix most focus bugs at once. However, due to the
runtime of e many things can get "randomly" focused, for exmaple: volume
control on the frame, internal dialogs, config value screens when
grabbing for keys, widgets when they get created in a gadget. The list
is quite long. However, fixing all those little bugs is hard and partly
impossible as the behaviour is correct in the context of a toolkit, not
in the context of a compositor.
Long term we should split window-focus and canvas-focus from each other,
then bugs like these would not be a problem anymore.
e is not ignoring the first unmap event on this reparent ... this
fixes that and the nextcloud app stops making e sit and spin at full
cpu and flickering tasks etc.
@fix
this will wipe out what the client set - this is valid for managed
clients only, not override windows.
this fixes teams and its big fullscreen sized window eating up events.
@fix
new chrome versions now set a CSd gtk property of 0 0 0 0 on
windows.... but set it later on thus confusing e into seeing
information changes for csd frame insets for a window that has no csd
frame but is ssd! this drops into a logic hole of "this shouldn't
happen" and weird stuff does happen. avoid this weirdness and just
assume a ssd window as normal then.
@fix
this can serve as a market - irrespective of icccm state that the
window is not visible. still - some apps like chrome/chromium. set
this so they are happier but this has side-ffects which are
client-local problems.
fixes T8923 ... i hope (seems to). ... but with side effects
@fix
so simple version: if firefox does CSD then when u press its minimize
(iconify) button it ASSUMES it will be iconified. it ASSUMES WM_STATE
will transition to iconic annd then back. it will cease rendering lots
of things when it thinks it is iconified when it isn't - e was
refusing because e wants windows tyo stay with live content so in ibar
and winlist and so on they keep showing updates). this assumption that
a wm will always iconify you when asked is wrong. a wm can refuse. so
basically firefox is brokne in its assumptions and logic. so work
around it but this leads to other fun things like clients stopping
rendering when iconified... as they now are told theya have been
iconified.
if theme doesn't support, fade-in will not happen (it'll just appear),
but if it does... e will fade to black for a restart, then fade back
in nice and cleanly.
Revert "fix spurious pointer jumps due to previous commit bugfix"
This reverts commit 550de9a680.
Revert "focus - fix emacs buffer switch focus set reported by felipe"
This reverts commit 690ab94c06.
emacs window (not in terminal). now in one:
ctrl+x 5 2 <- open new buffer
now we have it try switch to the other buffer:
ctrl+x 5 o
broken ... now fixed.
@fix
now it really does look for the right way to control per screen and
only use the new e_system back-end to query/list devices etc. ...
this now opens the door to adding ddc support to e_system then using
it from e_backlight.
i can't test this... yet - but this means in theory the backlight
gadget will control the backlight of the screen it is on...
many steam games don't provide much in properites - not enough to
match to a desktop file. the only thing that actually consistently
works is to use the STEAM_GAME property and match thyat to the uri
provided to the steam command in the exec of the desktop file. this
actually can work. nothing else works reliably across the board.
and man can games be horrible and playing nice with desktops and
having poor properties. even steam itself is not good. i had to add a
workaround for that too to match steam-runtime explicitly. :(
various errors we have are not actual errors but mostly information or
debug or status messages, so don't use ERR or just don't do the thing
that triggers it as it's useless. This leads to a less
noisy/error-like start output. cleaner for a release for sure.