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.
in the case where every binding until the end of the binding list has been rejected,
returning NULL must happen in order to inform callers that there is no more resolving
to be done, breaking out of an otherwise infinite resolve loop
ref fe5d2e6e61
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
I added a lower quality and less precise workaround for this before
since I didn't have enough test cases to think of something which would
be suffiently good to handle all cases.
as a result, initial calculations for obstacles would incorrectly detect
horizontally-oriented obstacles as being vertical, causing inconsistencies
in window placement. this would become even more severe if the obstacle
never resized itself, erroneously modifying window placement to position
around obstacles which did not exist
having a hint on the obstacle to indicate a direction is sufficient for
most cases, specifically zone useful geometry calcs, where obstacles are
expanded to cover the entire screen on which they reside and must expand
accurately based on the orientation of the obstacle
ref 10c43efc83
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
so every time i restart e i have my windows all messed up. it's
INSANELY annoying and time consuming every single time having to move
a dozen or more windows back to where they should be just because i
restarted e. i've narrowed it down to 2 places. 1 which is trying to
handle "out of screen" windows and during startup it seems things are
not quite stable yet as the randr code figures things out until the
event storm settles down.
when this is then fixed - another bit of code just shuffles windows up
all the time by a titlebar whcih is also supremely annoying. this is
the code that adopes a new frame for a window.
so the nasty hack to avoid piles of pain right now is for the first 5
seconds of e's life - don't do this stuff. at least you can now use e
and not be annoyed to hell and back every restart.
yes a nicer fix may be better - but that's going to take a lot more
time and patience and until then - this will do.
this allows video files to be played for wapapers - they loop and run
indefinitely. it is a special video object that shares the same source
across all outputs, so if you have the same video set, on 2 screens
(or desktops) then it's only decoded once and uses proxies to
ducplicate. this works in the pager too (it uses proxies).
this is for amusement and fun and ... because we can. :)
in the case where the existence of a zoomap in the comp frame edje has changed
during the course of changing the type, these callbacks must be updated with new
data params in order to ensure accurate operations during callbacks
This patch fixes an issue where building with wayland support but
disabling wl_drm module would cause compiler warnings about these
variables being defined but not used
Signed-off-by: Chris Michael <cpmichael@osg.samsung.com>
in many cases, a mouse action's callback will fail to execute as a result of multiple
objects being under the pointer at the time of the event. in this case,
the callback should be able to determine whether action callback processing should
continue.
as an example, when attempting to execute an action which only activates for
client objects, if the passed object is not a client then the callback should return
false to indicate that it was not able to perform the action for the given object,
allowing further actions to be attempted on this object
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
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
take_focus will only be handled if the new_client flag is set. in all
other casees, focus_set should be called directly
new_client flag implies changed flag
these was a workaround for handling early internal windows which is
no longer necessary now that they will handle their map states more
effectively
now, any wayland surface (not xwayland) requires a shell to map the
surface as intended
This reverts commit 67170f40a1.
this was changed intentionally to use the resource pointer in order to fix an
issue where external clients would reuse the same surface id,
thereby breaking the compositor with duplicate entries in the pixmap hash.
note, however, that internal windows in wayland DO use an int type pixmap id.
this is easily detected by checking the pid of the client for a window before doing
checks. this is necessary in order to be able to flag internal clients as internal
while still being able to match them with their surface id
also, uintptr_t is NOT indicative of an int type being used, it's an
int type which has the same size as a pointer, allowing casts between ints
and pointer.
Previously, we were passing in the wl window id into the
pixmap_find_client function. This is improper as the e_pixmap_new
functions take the surface resource id. To solve this, we will get the
Ecore_Wl2_window from the Evas_Object, fetch the surface id from that,
then pass those into e_pixmap_find_client.
This resolves an issue where the everything module was not working
properly.
ref T3058
Signed-off-by: Chris Michael <cpmichael@osg.samsung.com>
e_pixmap_new function
e_pixmap_new (when creating wayland windows) is expecting to get a
uintptr_t type passed into it (surface id). Previously we were passing
the entire wl_resource.
ref T3058
Signed-off-by: Chris Michael <cpmichael@osg.samsung.com>
icccm provides conflicting spec info regarding how this property should be set.
according to 4.1.3.1:
When the window is withdrawn, the window manager will either change the state
field's value to WithdrawnState or it will remove the WM_STATE property entirely.
however, 4.1.4 states:
Only the client can effect a transition into or out of the Withdrawn state
so to be on the safe(r) side, deleting the property seems to be the best choice here
ref 41daddeacc
fix T3011
it's possible for damage to occur before the show interceptor is triggered,
and in this case damages would be lost despite it being a valid usage
ref T3011
Summary:
currently there is ecore_x_current_time passed, which is the time of the
last event. if this is passed to ecore_x_window_focus_at_time the request can be
ignored because the last event can be in the past. Instead using
ecore_x_window_focus fixes this, because current time is passed, which
means that x is just using this event at the time it is called.
@fix T2948
Test Plan: Try to run spotify and try to trigger the bug, I cannot anymore.
Reviewers: zmike, raster
Subscribers: raster, abyomi0, cedric, billiob
Maniphest Tasks: T2948
Differential Revision: https://phab.enlightenment.org/D3471
shelf overlap can only take effect based on the state of this option:
specifically, overlap can only be enabled if border_fix_on_shelf_toggle
is enabled
these are generic objects which can be added to indicate that there
is something blocking window placement at the edge of a screen/desk.
this replaces the traditional method of watching shelves to calculate
useful geometry with a managed object which will automatically trigger
a recalc whenever it is updated, and it allows non-shelf objects to
more easily register themselves as obstacles for window placement
remove menu object from autoclose (if set) and ensure that only the
intended menu is deactivated in the autoclose callback
this fixes some cases where the wrong menu could be closed (or not closed)
due to race conditions with ecore and evas events
Summary:
printf %m stringifies and prints errno. This is actually hugely confusing
if used in error messages after failures that don't set errno.
You may get "Success", or you may get an errno that was harmless ages
ago.
Some of the functions followed by %m have only some error paths that
set errno, or make multiple system calls that can set errno
independently - knowing the errno at failure time is unlikely to be
useful in these cases.
Reviewers: devilhorns, zmike
Reviewed By: zmike
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D3571
This patch makes e_alert_main (the enlightenment_alert binary) work
for crashes when running with wayland (via the drm backend).
ref T2926
Signed-off-by: Chris Michael <cpmichael@osg.samsung.com>
Derek Foreman
Mike Blumenkrantz
Carsten Haitzler
Chris Michael
Marcel Hollerbach