We can now handle fullscreen X windows. X clients request to go fullscreen
buy sending a _NET_WM_STATE client message to the root window. When that
happens we call into the shell interface and asks the shell to make the
surface fullscreen. The shell will then resize the window, which causes
the X wm to configure the X window appropriately.
Make sure we ignore configure requests from fullscreened clients and send out
the synthetic configure notify as required in that case.
Finally, inspect _NET_WM_STATE before mapping so we can handle initial
fullscreen correctly.
In particular if the hash table lookup fails and returns NULL then that value
would be passed into weston_wm_window_schedule_repaint which does not accept a
NULL value.
It's pure WM-related function, so use the same 'weston_wm_' prefix that others
in the same file are already using.
Signed-off-by: Tiago Vignatti <tiago.vignatti@intel.com>
Since surface.commit was introduced, opqaue regions are stored in a pending
variable that isn't used until surface.commit. Xwayland uses the surface opaque
region as a way to tell weston what region of the surface should be opaque.
However when this pending opaque region was introduced, xwm was not updated
and so we have the 'black = transparent' problem again. This patch fixes the
problem by having xwm use the pending opaque regions.
Add THEME_FRAME_MAXIMIZED flag so the theming system can know not to draw
shadows for maximized windows. This allows maximized surfaces' content to be
sized and placed in a more expectable fashion.
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>
Remove weston_surface::opaque_rect completely.
Instead, set the opaque region in xwayland.
Before this patch, black text in xterm was transparent. Now it is not.
However, this patch fixes only a part of the alpha problem. If you apply
full-surface alpha with super+alt+wheel, the problem reappears. This
problem is still due to bad alpha channel contents on xwayland windows.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.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>
Commit eaee7841 took out the configure positioning of windows. This patch
brings it back and addresses also logic for resizing and sub-menus, that was
not covered on that commit.
Signed-off-by: Tiago Vignatti <tiago.vignatti@intel.com>
As per ICCCM 4.1.4 we're supposed to withdraw the window when we see
the real unmap or the synthetic unmap, whichever comes first. The
synthetic unmap may come after the window has been destroyed, so let's
just only handle the real unmap.
GTK+ sends an unmap_notify to the root window when a toplevel GTK+ window
gets unmapped. That may be a GTK+ bug, but we should just ignore events
from XSendEvent.
If a client sends another map request before the server has seen our
reply to the first map request event, we might get a map request for an
already mapped window. Just ignore that.
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.
Kristian Høgsberg