this requires that both canvas cursors and window cursors be present for the same
E_Pointer object, even though only the canvas cursor is actually visible
#kansas
this is only required for aliasing E_Client->comp_data as wayland compositor data.
if comp_data is never dereferenced, it is not necessary to declare the compositor
type
this used to be a marker for places where x11 functionality was needed,
but this has been simplified with the removal of wayland-only in configure
and so it is no longer needed
under wayland, some surfaces (eg. cursors) would attempt to show prior to
having acquired their actual size. these show attempts should be rejected
until the size has been set to ensure that rendering can proceed as expected
fix T2557
this is normally triggered by the engine/display server, but the drm
output is too powerful to be bothered by such trivial matters as
mouse events on startup
Summary: If we get here when curpage is NULL, we'll crash later, so we should test for it.
Reviewers: zmike
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D2793
Summary: If we get here when curpage is NULL, we'll crash later, so we should test for it.
Reviewers: zmike
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D2789
Summary: In some cases these end up uninitialized and we crash.
Reviewers: zmike
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D2788
this is impossible and will never be possible; ecore-x can only manage
a single x11 connection at any time, and so it will never be possible to both
manage the x11 compositor canvas on one xserver and manage xwayland clients
on a separate server
invalidates T2537
due to recent changes in ecore-input-evas, mouse events are propagated
differently; specifically, there are now "more" events than there previously were.
as a result, grabs on internal wins are no longer necessary, though they probably
never were necessary after the elm conversion
see 5cb6cdbc5e1a13ea0262e155983b494e6519abde in efl
I did an audit of this and it seemed that it no longer served the purpose
for which it was originally intended. specifically, this is for enforcing
click: raise/focus options, and so grabs must be in play on client windows
only when they are not focused to ensure that we get mouse events and can
then focus them. the grabs must then be removed once the window has focus
to avoid spurious mouse eventing
This fixes T2533 where the startup wizard would crash when run under
DRM due to the change in build options (xwayland support).
Signed-off-by: Chris Michael <cp.michael@samsung.com>
xwayland sets a wrong size on some (eg. menus) clients and wayland
cannot provide geometry or stacking information, so ensure that all
of this is copied over
also remove overrides from focus stack
This fixes T2531 where E would crash if the keymap could not be
fetched from xkb. Now if no keymap rules, model, or layout are passed
in we will default to a US keymap.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
this should fix the case of mouse-based focus policies trying to reapply
focus after another client has stolen it away without the pointer leaving
the window
in the case of different window <-> event_window, window is a child window
of event_window, and thus checking event_window here is valid (and necessary)
Like with all other wayland protocols I add the files generated with wayland
scanner here. Also the xml so we have the source around for updating and
modifications. We might want to think about wayland-scanner support in our build
system but this works for now.
The protocol prototype is hold simple and does only have a uuid signal and provide
call to handle the uuid assignment from compositor to app and app providing its
uuid if present already.
I have been running with this enabled for a while and it should not make
trouble but if it does simply reverting this one if totally fine while I'm
away.
The e_remember infrastructure already hooks into all needed places to keep
a record of the given properties for an e_client. We use this to update the
UUID store.
Signed-off-by: Stefan Schmidt <s.schmidt@samsung.com>
when you have click to focus we have a passive grab set up. somewhere
that window changed to the parent window instead of the client. this
leads to a side effect of a leave and enter event on clients for every
click. generally clients are ok with this, but some seem to have buggy
event handling. these enter/leave events are a side effect of the
passive grab even though we allow/replay the event.
this fixes that by placing passive grabs on the client window itself
instead of the parent.
@fix
This fixes Coverity CID1308395: Resource leak. Basically, don't bother
allocating 'source' if we are just going to end up returning due to
'eol' variable tests
Signed-off-by: Chris Michael <cp.michael@samsung.com>
these helper functions automatically account for "swapped" xwayland
clients and return the expected value from the wl client comp_data.
in this way, all of the current x11 compositor code can be reused with
minimal changes
in order to maximize the amount of reused code the following details the current
process for xwayland compositing:
* get map request from window
* force reparenting
* show window
* await WL_SURFACE_ID x11 message
* move x11 client data + pixmap onto corresponding wayland client
* business as usual with wayland compositing
this is pretty similar to the method of the reference code in weston,
except that there's no x11 compositor in weston
XWayland servers sends us SIGUSR1 when it has finished initializing,
so we should be checking the signal number when we get the event.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
NB: XWayland server needs the sockets setup prior to launching it so
we add some code to create & bind the needed sockets before starting
the XWayland binary
Signed-off-by: Chris Michael <cp.michael@samsung.com>
This is macro 101, you don't EVER put multiple statements in a macro
like that.
See Chris's commits, these broken macros already introduced (subtle)
bugs. Always surround macros in "do {} while()" unless you absolutely
can't (like when you declare a new variable to be used in the scope).
Why is it even there? I think we can safely assume eina log is available
for usage in E...
@fix
this is more of an academic case than any existing scenario, but
it's possible that an effect may be stopped by something attempting
to trigger another effect during the animation
previously the animating flag would receive an additional increment for
every effect, even if it was currently animating a prior effect, leading
to objects which were never deleted
Summary: Center a newly created dialog window when it is displaying off-screen. Fixes T2419
Reviewers: zmike
Subscribers: cedric
Maniphest Tasks: T2419
Differential Revision: https://phab.enlightenment.org/D2646
this allows improvements to the code which provides hide animations,
allowing clients to begin hiding during their show animations instead
of rendering a black rectangle
it's conceivable that, were there a bug in client refcounting,
this could become an infinite loop and prevent shutdown/restart.
since, at this point, we don't really care about deleting anything,
ensure that the loop will end
this follows 56cabf59c6 then
4e5521b4d8 where i have been trying to
fix a crash with e client and comp win references etc. i have gone
over all referencing with a fine tooth comb and found all the nigglies
i can., no leaks now, no crashes, no valgrind complaints etc. so i
call this fixed now. as best i know this is new in e20, so not a
backport fix
refs were inconsistent - thus this fixed the fullscreen quit bug by
never freeing a client. this brings the bug back by fixing this client
leak. i'll look again at this later.
the refcoutning for e_comp and e comp clients seemed to be a bit off -
i read over every ref and unref carefully and fix it. this leads to
the com-_data being null (properly now), so now check for that too.
Summary: fixed window focus and keyboard input issues if the to-be-focused window is in an iconized state
Reviewers: zmike
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D2644
Summary: Sometimes a window has a name that's not like the application name, for example. chromium-browser application will have a window name: Chromium-browser. Most users will try to match the window name with "chromium-browser", but it wont work b/c the e's window name match is case sensitive. Most users, would not know that the window name of chrome is "Chromium-browser", so it is pretty much impossible for them to setup a focus-to-window-name binding properly.
Reviewers: zmike
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D2645
these are specific types of animation for use when toggling window visibility.
they combine with existing compositor window animations to provide nicer integration
for very specific types of windows
see https://www.youtube.com/watch?v=hIVdd0Z2K00 for a demo
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
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 reverts commit 718b3206cb.
no - this REPLACEs the mixer module. the same old mixer gadget that
was originally in e now will be replaced by this new epulse/emixer
gadget. thus the "mixer" gadcon name.
Mike Blumenkrantz
Chris Michael
Carsten Haitzler
Derek Foreman
Stefan Schmidt
Stefan Schmidt
Tom Hacohen
Yomi
Toan Pham
Toan Pham