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.
for fast we probably should look at something like having a multiplier
on edj transitions and set it to 0 to make it instant. this would be
much better and able to apply to ALL effects... so let's remove this
way for now. as for no shaodws and other stuff - moving to wl cant
control CSD and even then it's a theme look ant feel - a "flat theme
withotu any shadows" would just not have them. probably not a checkbox
to have here.
x11 modifier handling in events is broken: the modifier state is the state from
before the event, meaning that pressing caps lock will never result in an event where
the modifier is not set in the corresponding event
wayland handles this more sensibly, though it should be detected on key up rather
than key down
fix T5737
many times it's useful to have an event for actual zone geometry change
vs useful geomtry change, so split this out and use the right handler where appropriate
we have some visual glitches i'm on a mission to fix... and the above
is one of those. timeout for lock should begin after screen has gone
black first.
key presses during desklock should only be received by the lock implementation
and not by any other handler. this ensures that nothing unexpected can happen
with focus and simplifies overall key handling
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 patch adds new methods to the screen interface that we can use
inside wl_drm to determine if a key event is eaten or not. This fixes
an issue where VT-Switching would not work if an application was on
the screen (E-Wayland).
Signed-off-by: Chris Michael <cp.michael@samsung.com>
in many cases where a zone's useful geometry is marked dirty, the resulting
recalc ends up having the same useful geometry as before: this is the case
for things like tasks gadgets, which continually expand and contract along
a single axis and thus will never affect useful geometry while still forcing
a recalc
by ignoring these cases, a huge amount of compositor thrashing is avoided and
a number of related bugs can also be fixed
this function is only called when screen geometry (or useful geometry) has
changed, and so all clients should have their geometries checked at this point
to ensure that they update for any new zone obstacle changes which have occurred
these bindings activate before any other handler can process the
corresponding event and will block all propagation of the event upon
activation
as an example, the alt+wheel default binding for flipping desks currently
passes through a number of event handlers prior to activating the binding,
meaning that it's possible for the wheel action to have unwanted effects
when these handlers cause actions before the binding stops the propagation.
using a MANAGER context instead ensures that this is not possible
this removes the per desktop profile config and replaces it with a
per-screen one that is tied to a specific display so it is far more
logical than per desktop. this allows e to set up different scaling
per screen for apps that use elementary for example via this derived
profile.
this of course is slightly problematic for e itself since it now uses
elm - as this will cause e to go kind-of-crazy with differing profiles
as it fights with itself and elm if 2 screens have different profiles.
this requires elm to be fixed to allow custom profiles per window.
this also currently won't switch profile of a window when you
reconfigure screens.
@feature
xx
elm win intercepts this callback in order to maintain internal sizing
for use with elm widgets on the compositor canvas, so it's necessary to
get the callback from this object in order to accurately update the canvas
during resizes
due to enabling manual rendering (and als animator frametiem to 10
secons) in e_comp_canvas.c when screensaver is active (blanking is
finished totallly - eg the fade to black) evas weill nto render the
last frame of the animation - skipping it and not rendering another
update until screensaver is disabled. this leaves a subtle ghost of
pixel data which is 1 step before black on the screen (until dpms
turns the monitor off).
this fixes that. this delays enabling manual render for 1 more second
after we have been told the screensaver is active. this is plenty of
time to update all the way to black.
@fix
so e has a bit of a problem. we mostly deal with zones, BUt these
zones come from our old xinerama code (this likely should just die
some time) and THIS code gets fed info from e's randr code. we
re-fill/modify as randr finds new screens or things get reconfigured.
thus zones adapt. the problem is now all our zone code really has a
hard time reverse mapping the zone back to where it came from -eg the
randr screen data. you literally can't do a whole bunch of things like
know if that zone was an internal laptop lid or an external screen, or
if it was rotated or even what the dpi is... as you ave no deasy way
to map it back other than by guessing geometry matches.
this fixes that by storing the randr screen id (which should be
unique) fromt he original src randr screen in the xinerama screen and
then in the zone. with this you can do a quick lookup in the e randr
data should you ever need to find the info. this should pave the way
for some other fixes/improvements, but without this they cannot be done.
@fix
Elyes HAOUAS
Carsten Haitzler
Mike Blumenkrantz
Derek Foreman
Chris Michael