They belong in the compositor rather than libweston since they
set signals handlers, and a library should not do that behind its
user's back. Besides, they were using functions in main.c already
so they were not usable by other compositors.
Signed-off-by: Giulio Camuffo <giuliocamuffo@gmail.com>
Reviewed-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
The xwm used to automatically send to Xwayland the position of X windows
when that changed, using the x,y of the primary view of the surface.
This works fine for the desktop shell but less so for others.
This patch adds a 'send_position' vfunc to the weston_shell_client that
the shell will call when it wants to let Xwayland know what the position
of a window is.
The logic used by the desktop-shell for that is exactly the same the xwm
used to have.
Reviewed-by: Derek Foreman <derekf@osg.samsung.com>
Reviewed-by: David Fort <contact@hardening-consulting.com>
This patch adds the maximize button to the window frame for the windows
which set the MWM_DECOR_MAXIMIZE hint, and it wires it with the shell
via a new method in weston_shell_interface.
Additionally, it also listens for the wm hints coming from the client,
but it doesn't support maximizing a window only vertically or horizontally.
The window will be maximized only when both directions are maximized.
Reviewed-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
Some X clients use the _NET_WM_DESKTOP property to tell if the window
is mapped or not. If set, it should say the virtual desktop the window
is currently in, if unset it means the window is unmapped.
The xwm currently has no way to know how many virtual desktops
the shell plugin has, or if it even implements the metaphor. For now
just set the property to 0, meaning the first desktop, if the window is
mapped, and delete the property when unmapped.
Reviewed-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
xeyes works as expected now. subwindows are popped also as expected. This
patch should fix the following:
https://bugs.freedesktop.org/show_bug.cgi?id=59983
Signed-off-by: Tiago Vignatti <tiago.vignatti@intel.com>
We used to rely on an ugly hack where the xwayland server would always
report RGB X windows as having ARGB pixels, so that texturing from these
would also sample the undefined alpha. We also relied on Xrender rendering
to RGB X windows to write the alpha channel correctly, so that when we
texture from the RGB X window as an ARGB surface we end up getting the
alpha written by Xrender.
That was obviously all broken. We can instead reparent client windows into
ARGB frame windows. That way we can render the decorations using a
ARGB render pictformat and sample back those alpha values in a well-defined
way. We can also unbreak xwayland and let it report RGB pixel format for
RGB windows. We still need the opaque region or the RGB-only client window
but that's OK.
Xeyes is the counter-example that fails on that heuristic and won't be caught
on kill binding. This and the last two patches should fix:
https://bugs.freedesktop.org/show_bug.cgi?id=53679
Signed-off-by: Tiago Vignatti <tiago.vignatti@intel.com>
On X the global absolute coordinates are sent in ConfigureNotify and transient
windows are mapped exactly on that position. On Wayland we don't have the
concept of global coordinates, and that's a problem for transient surfaces
without transient_for set because they rely on such hint for setting their
positioning.
So this solution is a workaround. It guesses a parent based on the last
focused window to determine the relative position of the transient surface.
This put transient windows of Chrome browser back to work.
Signed-off-by: Tiago Vignatti <tiago.vignatti@intel.com>
We just print properties when they change now instead of dumping all
properties whenever we re-read them. Also, make the property output a
little more concise.
Giulio Camuffo
Benoit Gschwind
Bryce Harrington
Kristian Høgsberg
Tiago Vignatti