it seems that since the first version of the enlightenment compositor
in e17, damage events in x11 have never been used correctly. using
the event struct members will only give the bounding box/area instead
of the damaged regions; the real regions must be explicitly fetched
from the server
this removes the need for a lot of hacks which were added over the years
to make override windows render correctly, and also probably reduces
rendering overhead slightly
Summary:
@fix The list of icon themes in the search list is quite out of date
it doesn't include the icon themes used by gnome3 or kde4/5 this means
for a lot of users at first boot e has alot of missing icons.
The Icon sets that have been added are as follows
"Oxygen", /* KDE 4 */
"Adwaita", /* Gnome 3 */
"Breeze", /* KDE 5 */
"HighContrast"
This change will cause T1732 and T1923 to not occur for almost all users
but it does not fix them properly the code should be modified to fall back
to pick up icons from fallback locations such as the hicolor theme if no
icon theme is set.
It would be nice if someone could backport this to e19 I don't know how to
Reviewers: bu5hm4n, zmike, raster
Reviewed By: raster
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D2377
some systray indicator icons are not found because the sizes are not
in the list. fix this. this SHOULD actually use our existing efreet
icon theme finding to auto-switch file based on size changes.
if another callback triggered the creation of a deskmirror visual while
the dirty callback was in place, a second mirror object would be created
leading to an orphaned mirror object which retained references to the dm
client and eventually resulting in a crash
the currently visible desk for a zone is stored on the zone struct, so
iterating here is unnecessary. furthermore, at the time when a desk is hidden,
a client may begin receiving mouse events which could trigger a focus-set and
lead to another desk flip. at this time and only this time, the "current" desk
will be marked as not visible, and so this sort of desk show must be rejected
fix T2676
in the case that the canvas window has just had focus set on it, apply this focus
and ensure that no client retains focus
this resolves a race condition where focusing the compositor canvas <-> client
extremely quickly would result in a client trying to steal focus when it was
not actually focused
a notable (but trivial) side effect is that now when flipping desks at high speed while using
mouse-based focus policies, the user is almost guaranteed to end on a desk which
has open windows on it
in the case of recursive desk flips, toggling a desk's visibility may
erroneously send queued evas events to the client's frame object, leading
to a focus-set (mouse-based focus models) which triggers a desk flip
inside the original desk flip. this "inner" desk flip is spurious and
should be ignored
it seems that the reported damage events upon resizing an override window
are not accurate, and so we must force a full damage here while avoiding a
render queue in order to ensure that the full contents of the override will
be rendered in the next frame
fix T2045
this seems to fix an extremely rare issue related to both deskmirror artifacts
and crashes in deskmirror during restart; I was only able to reproduce the crash
twice in the span of over an hour of testing and it seemed to disappear after
this change
deferred focus should no longer be valid if a client has been hidden
before the focus-set could be triggered
fixes super fun infinite loop with desk flips
it seems that some changes now make the shel menu post callback be
called for older menus not part of the shelf and thus shelf menu
stored != menu the cb is for - thus resulting in deletion of the wrong
menu
this has been in e for ages - someone not noticed, but this fixes
visual artifacts of left over menus on the top-left. this extra ref
really makes no sense. it's not like this ref is then accomoanied by a
matching unref somewhere else (after much debugging).
@fix
in the case that a client is going to be shown on the next loop iteration,
focus setting must still occur and be deferred
this fixes the case of a window appearing on a desk while the user is switching
desks away from it even though this window is attempting to focus itself
this is a not-great way of hacking around various issues related to
the efl mouse button cancel patches that went in for the 1.15 cycle
which changed the entire mouse input workings of the toolkit.
to avoid further issues, the compositor will explicitly block eventing
on all internal canvases during actions
these are triggered "in passing" when mouse in events occur and do
not necessarily indicate that the mouse has entered this specific window
failing to reject such events can cause mouse-based focus policies to
attempt to set focus onto windows which are not visible, resulting in
an infinite loop where no window is actually focused
in the event that these windows are different, event_window is the parent of window
which may or may not be explicitly tracked by an E_Client, so the wheel events here
should be sent to the parent as is done in mouse button events
fix T2604
canvas grabs changed completely in 1.15, and so it's required that
x11 grab handling also have special runtime cases for this
for such versions the compositor must:
* always grab the internal client window instead of the parent
* always ungrab the window when it has focus
Mike Blumenkrantz
Simon Lees
Carsten Haitzler
Cedric BAIL