when an app tries to position itself before being shown, attempt to store this
and apply it in order to effectively handle cases where an app attempts to show
on a specific screen, e.g., presentation apps which show a console on one monitor
and the presentation on a different monitor
fix T1571
e_client_under_pointer_get() ignores overrides.
ref 3ee5a0378d
fix T5878, T5871
IF ONLY THERE WERE SOME METHOD FOR TESTING COMMITS BEFORE THEY WERE PUSHED
so we egnore some mouse in evets due to their flags (crossing events
thansk to grab changes or other stuff) that we want to ignore for
other reasons like when a popup menu happens and so on... so if we get
a mouse in... 0.1 sec later double check where the pointer is with a
poll then fix focus. this should patch over a long standing annoyance
here in x11.
@fix
some apps (e.g., wine) do not trigger any event when changing this property,
and they use the property in order to simulate window fade in/out
ref T5370
in the case where the desklock timer was longer than the blank timer,
this would permanently break input
input is still broken for the duration of the screen blank animation and
any time the screen is blanked
This reverts commit 7bc179da5a.
this now totally broke the glitch fix and it now animates in reverse
on suspend and does nothng on resume... testing might be a good idea
beforehand...
this requires we have to force dpms on to reduce power. to avoid
glitches with the pointer staying around in x we need to support
suspending it too so it hides cleanly like the screen dims or undims.
also use the new powersave freeze mode to do this.
note that i've tested this on s3 supporting laptops and non-s3 and it
"works for me". it may require more testing and work. there is more to
power saving than just this as well but for now that's out of scope as
you have to mess with linux device autosuspend timeouts and a bunch
more (wowlan ... blahblah).
i need to find the source of the intermittent wakeups too in e. there
is a long lived timeout (8-ish seconds?) but more specifically e keeps
waking up from fd's and then reading /sys stuff about battery - some
event is causing us to do this... maybe to suspend this or make
battery checking very rare when in freeze mode (or screen off) etc.
so this fixes some glitches as well as supports a new way of sleeping
"alive" when hardware literally doesnt support normal s3 sleep... so
kind of a fix with a feature.
this is supposed to handle the case of state changing from withdrawn
to normal, but attempting to show an iconic client in this case results
in dead windows on screen
fix T5444
in the case where an app unmaps and maps its window very quickly, this
allows detection of the maprequest event which will occur with the just-deleted
manager window so that the window can be correctly managed again
fix T5348
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 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 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>
this adds core basic handling for window stacks where windows behave
correctly as a single unified stack something like what naviframe does
but out-of-window so you can including multiple processes. only on x11
right now as it's being supported/worked on.
as we dont plan to kepe naviframe in future, this is the way to go.
naviframe "pages" will be windows in a stack. the wm should do the
nice thing. in e this will be very nice. for now elsewhere we use
transient_for so a wm would treat this like a bunch of dialogs with a
single parent window. i guess in a desktop thats probably what you
might expect. e will be a little more "finesse" filled.
need to make ibar, tasks,m win menu and winlist (alt-tab) respect this
and only show the top member of a stack.
need to send messages to clients when they are "top" or "middle" or
"bottom" or "alone" in the stack or something so decorations can change.
should add soem new border signals in theme (for both SSD and CSD) to
make this look nice. will need some config additions for that and
ability for e comp to do the right thing
but this is a solid start
this allows different display protocols to start their applications at
different times to ensure that any initialization has completed prior to
starting anything requiring a window
fix T3475
so i was profiling today .. leak hunting .. and i noticed. if you have
enough appss open - eg terminology, e uses a huge amount of memory...
for icons. terminology is 128x128 ... thats 64k per icon. open up a
lot of terminology windows and we duplicate that 64k per every window
on the wm sside because we get the data. it would apply for any app
that sets a netwm icon. this can be come rather silly if you have like
100 terminals. it's worse with larger icons (eg 256x256 - 256k per
icon).
this puts in a simply list for shared icons and a lookup on fetch to
de-duplicate and share icon data. this should drop memory usage
nicely.
@improvement
if multiple x11 clients receive focus during the same mainloop iteration,
an almost unbreakable cycle of window focus chaining will occur, resulting in
both windows being focused simultaneously--or so it appears--which results in
no window being able to receive input. to avoid this, ensure that only one x11
client can receive focus in a given loop iteration
due to event bursts, it's possible for multiple x11 clients to receive
mouse in events on during the same main loop iteration. in this scenario,
only the last client has received an actionable mouse in, and applying this
event after the dispatch has completed ensures that multiple clients do not
all receive mouse in+out events during the same loop
this greatly improves mouse-based focus reliability in a number of cases
This reverts commit 26a7ba3a58.
this can only occur if something forces an event flush during shutdown.
in this case, whatever is triggering the event flush is a bug, not the
dereferencing of a pointer which is guaranteed to exist for the normal
lifetime of the process
in the event of a wayland start, x11 comp init will fail, meaning that
cleanup must occur in order to avoid erroneous triggering of x11 handlers
#TooSoon
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
the values requested by the client will be based on its geometry and not
the geometry of the frame. using the frame geometry here results in windows
moving ↘ based on the top/left frame sizes
fix T2912
in the case that a mouse move event occurs, the compositor should validate
the event to ensure that the mouse cursor is actually over the window that
the event claims to be from
fix T2594
in order to continue rendering an iconic client without breaking icccm,
it's necessary to map the client's window again and unset iconic state
whenever rendering is needed, then re-set states when rendering
stops
ref T2788
E_Client->comp_data is null after a client has been deleted, so
attempting to handle events which require the dereferencing of this
pointer after a client has been deleted will result in a crash
these events should be rejected after delete regardless, since at this
time the compositor has stopped handling events for the client
ref f42c6aa187
i got a crash here and the bt was broken and i couldnt check if
_e_comp_x_client_data_get() returned null, but it's the only thing
that would make sense, so protect against this to avoid a crash. as
this was a one-off, i can't find out more,
@fix
in the case where a shaped window with many rects exists, there is a high
probability of the damage rect count being huge, leading to massive blocking for
each frame as the compositor attempts to fetch all of these rects from the xserver.
instead, the compositor can shortcut this by forcing a full-window damage any time
the rect count is sufficiently high, trading a blocking socket operation for some
amount of (potential) overdraw.
testing in affected scenarios has shown huge improvements: where previously the entire
compositor would lock up, things work as expected now
see https://bugzilla.mozilla.org/show_bug.cgi?id=1214746 for a sample case
it seems that damages for popup windows in some applications,
namely blink-based browsers, are reported incorrectly, resulting
in sometimes having a blank window