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
keys such as tab will have different names in key and keyname, eg.
"Tab" vs "ISO_Left_Tab", and both names are valid for comparisons
thanks to @billiob for pointing out this regression
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 fixes an issue where shrinking vertical shelves would cause vertically
maximized windows to always match the height of the shelf
possibly needs improving later depending on usage of zone obstacles in
the future...
in the case where an ANY context action exists and a SPECIFIC context action
also exists for the exact same binding (eg. alt+click), the action which was
added to the config first would be activated
this is unreliable and confusing since it's impossible for users to determine
the order without either manually examining the config or clearing all bindings
and starting over, and this presupposes that the user is even aware of such an
issue
instead, now the most specific binding context will be chosen, with ANY used only
as a fallback in the case where no other binding could be activated for a given
scenario
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
wayland requires a ton of boilerplate code. anything that can be done to
reduce the amount of work (copy/pasting) required to handle extension adding
is a plus
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 bindings activate before any other handler can process the
corresponding event and will block all propagation of the event upon
activation
as an example, the alt+wheel default binding for flipping desks currently
passes through a number of event handlers prior to activating the binding,
meaning that it's possible for the wheel action to have unwanted effects
when these handlers cause actions before the binding stops the propagation.
using a MANAGER context instead ensures that this is not possible
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
When VT switching away and back, the kernel uses SIGUSR1 and SIGUSR2
to notify us of a vt switch event. That same signal was being trapped
here to toggle display of the 'fps' window. If we check the signal's
si_code, we can tell if this signal came from the kernel (as in vt
switch) or from the user (as is sent in 'kill'). This fixes the issue
of VT-switching back and forth under DRM would cause the compositor
'fps' display to appear.
Signed-off-by: Chris Michael <cpmichael@osg.samsung.com>
a cursor client should be shown/hidden as needed despite its lack of a
shell interface, and having a special flag to identify these types of
surfaces makes it easier to do that
in some cases it might be desirable to remap a mouse button to a key.
this is not very user-friendly since it requires device-specific key names
which need to be translated to/from files such as /usr/share/X11/xkb/keycodes/evdev
#SamsungFeatures
in automated testing scenarios, being able to generate input events is useful
for detecting regressions related to keyboard actions
this depends on an xkbcommon function which is expected to be in the 0.6.0
release, so dlsym here in order to make that a runtime dependency for now
since this is not going to be a widely-used feature
#SamsungFeatures
Mike Blumenkrantz
Chris Michael