a client with this flag set here is unreliable to use as a stacking
reference since it has yet to be stacked and can be located anywhere
in the window stack.
fixes internal window stacking on startup
blocks execution of resizes until the surface commit arrives. reduces
the race condition between resize and render and eliminates frame drops
during slow resizes
NB: e_comp_wl_input_keyboard_modifiers_update already sends keyboard
modifiers to all keyboard resources, so no need to call this twice.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Key state updates need to be consistent. As we update the key state on
key up regardless of client focus, then we should be doing the same in
the key_down event handler so that key state remains consistent.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
e_comp_wl_input_keyboard_state_update already makes a call to
e_comp_wl_input_keyboard_modifeirs_update so there is no need to call
it twice on key up/down events.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Summary:
previously e_bg_del didn't take the zone paramater into
account
fixes T2572
Reviewers: raster, zmike
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D2810
xwayland compositing requires that we set up a root window cursor image
immediately since we'll be getting that cursor surface to display as soon
as the pointer goes out of an x11 client's window
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
Summary: In some cases these end up uninitialized and we crash.
Reviewers: zmike
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D2788
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>