if a file called ~/.e-mtrack existed then during startup the launcher would
read the first line of this file and set LD_PRELOAD to that value
CID 1039785
if the option to always raise a window on click is enabled, clicking an internal
window in a way which creates another window will cause a race condition where
the clicked window is raised over the newly created window
there is no obvious policy-wide solution to this issue, but making this change
at least resolves the issue in question
fix T3210
using pointers for this turned out to have some corner case collisions, so
now just use something totally unrelated to the surface to ensure uniqueness
eina list stopped using eina_error like... so so so so so long ago like
before 1.0 - so eina_error value may be something junk and from
somewhere else where the list append succeeded but ena error said
fail- and that is what was happening and things crashed. this fixes this
@fix
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
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
Mike Blumenkrantz
Carsten Haitzler
Derek Foreman
Chris Michael