This fixes an issue where maximizing a window would set improper xdg
surface window geometry. We receive window configure sizes based on
xdg surface window geometry, so we need to subtract framespace there
or else window size grows when maximizing/unmaximizing multiple times.
This also adjusts the call to xdg_surface_set_window_geometry to
account for framespace (Fixes T2842).
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
by using the geometry from after the request size has been updated,
scenarios such as the following can be avoided:
[4208305.332] xdg_surface@46.set_window_geometry(0, 0, 1778, 1)
[4208305.370] xdg_surface@46.set_window_geometry(0, 0, 1778, 250)
@fix
if a state change occurs on the ee, related callbacks must be run prior to
performing any resizes in order to ensure that the correct csd sizes are
calculated
@fix
ref T2841
This fixes an issue where maximizing a window would set improper xdg
surface window geometry. We receive window configure sizes based on
xdg surface window geometry, so we need to subtract framespace there
or else window size grows when maximizing/unmaximizing multiple times.
This also adjusts the call to xdg_surface_set_window_geometry to
account for framespace (Fixes T2842).
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
by using the geometry from after the request size has been updated,
scenarios such as the following can be avoided:
[4208305.332] xdg_surface@46.set_window_geometry(0, 0, 1778, 1)
[4208305.370] xdg_surface@46.set_window_geometry(0, 0, 1778, 250)
@fix
if a state change occurs on the ee, related callbacks must be run prior to
performing any resizes in order to ensure that the correct csd sizes are
calculated
@fix
ref T2841
by using the geometry from after the request size has been updated,
scenarios such as the following can be avoided:
[4208305.332] xdg_surface@46.set_window_geometry(0, 0, 1778, 1)
[4208305.370] xdg_surface@46.set_window_geometry(0, 0, 1778, 250)
@fix
Summary: When an initial client application was shown and we tried to
resize it, the resize would jump by the amount of framespace. This was
because the xdg_surface@configure event would be sending window
geometry as the width/height params in the event. We need to account
for that in the callback of window configure and adjust size
accordingly.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
if a state change occurs on the ee, related callbacks must be run prior to
performing any resizes in order to ensure that the correct csd sizes are
calculated
@fix
ref T2841
This fixes an issue where maximizing a window would set improper xdg
surface window geometry. We receive window configure sizes based on
xdg surface window geometry, so we need to subtract framespace there
or else window size grows when maximizing/unmaximizing multiple times.
This also adjusts the call to xdg_surface_set_window_geometry to
account for framespace (Fixes T2842).
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
by using the geometry from after the request size has been updated,
scenarios such as the following can be avoided:
[4208305.332] xdg_surface@46.set_window_geometry(0, 0, 1778, 1)
[4208305.370] xdg_surface@46.set_window_geometry(0, 0, 1778, 250)
@fix
Summary; This fixes an issue where maximizing efl/elm apps in Weston
and in Enlightenment would cause extra space to be left around the
window.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
in the case of operations which change framespace, rejecting resizes
at this point will cause the canvas to fail at resizing and result in a
partially-rendered canvas; the real canvas geometry must be calculated by
running the entire function in order to determine whether the resize is valid
fixes toggling borderless state of windows
when running in a wayland compositor, the ideal mode of operation is to
only prepare/send frames when the compositor has finished with the previous
frame
to achieve this, manual rendering can be toggled upon creating and completing
a frame callback, ensuring that a canvas never has multiple pending buffers at
any given time
fix T2784
when a render occurs, frame callbacks must be managed in order to ensure
successful rendering for future frames. the best place to do this is in the
engine here, since this is the lowest-level place which has access to both
the wl_surface as well as the evas rendering state
ref T2784
Summary: If we have already resized this ecore_evas to be what we
want, then there is no point in running the below resize code as we
should already be at the requested size. Add a test at the beginning
to see if we have already set these values
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
for framespace
Summary: As we have already adjusted for framespace in various code
leading up to a configure callback, don't adjust for it here. This
fixes an issue where xdg surface window geometry would get incorrect
values which were including framespace. The values of the
xdg_surface_set_window_geometry should be Just the geometry of the
visible window.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
processing updates
Summary: When processing render updates, we should be checking if the
Ecore_Evas "should be visible" property is set.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Summary: As we no longer need the wdata here (see previous commit), we
can remove the usage of this variable
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Summary: This function should really not be called here as it triggers
an xdg_surface_set_window_geometry call which (in turn) should only be
getting called when the window geometry (meaning visible region)
itself has changed.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Summary: As we end up calling ecore_evas_wl_common_resize anyway,
there is no need for all these size calculations in the configure
callback. The resize function will deal with this anyway.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Summary: If we are calling ecore_evas_object_cursor_set with a NULL
object, then we need to inform the ecore_wayland window that we no
longer have a cursor surface.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
engine
Summary: Frame callbacks are now handled inside the engine itself and
are thus not needed here anymore
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
configure event handler
Summary: This patch ports the fix for windows without a min/max size
being set over to the configure event handler (which was also not
taking into account the fact that Some windows may Not have a min/max
property set on them.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Summary: This fixes an issue for windows which do not set a min or max
size in the properties. This was discovered when running Enlightenment
in a Wayland-Only scenario, and trying to bring up the settings panel
which would cause an endless loop in calculating the proper window
size due to min/max not being set.
@fix
NB: Thanks to Mike for the help in tracing this ! :)
Signed-off-by: Chris Michael <cp.michael@samsung.com>
xdg_shell protocol supports minimizing surfaces. When elm apps request
iconification, they will call ecore_evas_iconified_set which in turn
will make use of the newly added ecore_wl_window_iconified_set function.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Recent expedite changes have uncovered an issue where the ecore_evas
(under wayland) was not supporting async rendering correctly. This
fixes the issue so we can run expedite with -y and get redraws again.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
ecore_evas_cursor_object_set
NB: Previously, if we mad calls to ecore_evas_cursor_object_set to update the
mouse cursor hotspot, the mouse cursor would be repositioned at 0,0 on
the canvas due to x & y being set to 0,0. We fix that here by fetching
the current mouse position Regardless if we are changing the object or
not (ie: perhaps we are just updating the hotspot and not the object)
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Chris Michael
Mike Blumenkrantz
vivek