As we require wayland 1.10 now, there were missing functions for the
wl_data_source interface. This patch just adds placeholders for those
missing functions until we can implement them
Signed-off-by: Chris Michael <cpmichael@osg.samsung.com>
As we require wayland 1.10 now, the wl_seat_interface implementation
was missing a function pointer for the 'release' request. This patch
just implements a function placeholder until we can implement it.
Signed-off-by: Chris Michael <cpmichael@osg.samsung.com>
As we require wayland 1.10 now, there were missing functions for
wl_data_offer interface. This patch just adds placeholders for those
missing functions until we can implement them
Signed-off-by: Chris Michael <cpmichael@osg.samsung.com>
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.
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
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