The resource destroy callback for frame callbacks will walk the frame list
to remove itself. When freeing that list we need to make sure the
resource destroy callback doesn't see the same list we're walking and
corrupt it.
_e_shell_surface_destroy() is already the implementation's destructor, so
it'll be called when the surface is destroyed anyway. What we have to do
here is just call wl_resource_destroy(resource) - which will call that
function for us.
It'll also do us the favor of actually destroying the resource and
removing it from the client's resource list so we won't get a SECOND call
to _e_shell_surface_destroy() on client exit.
There are 3 places a frame callback could be hiding. frames list,
pending.frames list, or subsurface cached.frames list. We weren't
clearing it from the subsurface cache on destruction.
for whatever reason, there's a global option which makes windows adjust
when a shelf autohides as well as a per-shelf option to ignore the global
option
in the case where the global option is not enabled, there is no reason to
check the per-shelf option
ref 5d63b07ca3
Summary:
It's apparently possible to trigger at least some of these by interacting
with a client as it's closing, so add a bunch of checks.
Reviewers: zmike
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D3699
this case is solely for handling clients which are created with nonzero
position, eg. an x11 window trying to display itself centered upon initial
creation. re_manage indicates a window which is re-managed after a restart of
enlightenment, so these windows clearly do not fall into that case
fixes an issue where windows would move up+left by the size of their frame during
restart
ref 95e133282e
if the existing map is left enabled when the child is removed from the
zoomap, the child object will be permanently misrendered with the previously
applied map
according to xkbcommon, the group returned from serializing the EFFECTIVE layout
is the one which is currently active. this array index should match up with the
list used in the xkb part of E_Config
this used to be handled by the "shaped" flag back when shelves had their
own windows, but the handling for it was lost during the transition away from
the E18 compositor
the drm screenshot action forcefully iterates the main loop, causing
the current loop (which triggered the action) to return after the screenshot
action has ended. during this time, it's possible for other actions to also
trigger, including triggering subsequent screenshot actions, so it's necessary
to defer the execution of the action until after the initial loop which triggered
the action has returned
#Recursion
these are all cases where bindings should fail to activate in order to
avoid interfering with current operations
also fixes an issue where attempting to add or modify an existing
mouse/key/wheel binding would fail as a result of that binding activating
while the grab dialog was active
currently there are a lot of workarounds for inhibiting these bindings,
but it's getting harder to keep track of all the conditions and cases
where bindings need to be worked around
this should greatly simplify the process of toggling binding activation
in cases where such behavior is undesirable
acpi bindings are always allowed since they are unlikely to interfere with
operations where direct-input bindings would be harmful
in the case where the xwayland pixmap has previously been marked as usable,
the corresponding client is guaranteed to have gone through the new_client
eval. allowing a second eval will result in wrong geometries being set for
the window in some cases
if an action triggers on a window, the triggering mouse event should
not be passed to the window. the only way to determine this is if the
action object lives through the entire event
When VT switching away and back, the kernel uses SIGUSR1 and SIGUSR2
to notify us of a vt switch event. That same signal was being trapped
here to toggle display of the 'fps' window. If we check the signal's
si_code, we can tell if this signal came from the kernel (as in vt
switch) or from the user (as is sent in 'kill'). This fixes the issue
of VT-switching back and forth under DRM would cause the compositor
'fps' display to appear.
Signed-off-by: Chris Michael <cpmichael@osg.samsung.com>
a cursor client should be shown/hidden as needed despite its lack of a
shell interface, and having a special flag to identify these types of
surfaces makes it easier to do that
take_focus will only be handled if the new_client flag is set. in all
other casees, focus_set should be called directly
new_client flag implies changed flag
in this case, mouse events which are not originating from the internal
window are for the screen, and these coords can be used for determining
"mouse out". if the mouse event comes from the window, it is inside the window.
ref 7c661b54a9
these was a workaround for handling early internal windows which is
no longer necessary now that they will handle their map states more
effectively
now, any wayland surface (not xwayland) requires a shell to map the
surface as intended
these types of surfaces should grab focus as early as possible, and
setting the flag at this time ensures that it will be handled during
the next client eval
if windows are created during startup, they will attempt to show themselves
before xdg surface operations are available, leading to a scenario where they
will never successfully map themselves. if the elm win object is visible, this
indicates a mapped internal window, so directly call the map function at this
time to make the window visible