mousing over a window for an x11 client should always yield x11 mouse events
in cases where mouse eventing is required; any events occurring on the comp
object in other cases inside the xwindow region are able to be ignored
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.
_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