Currently, there is a fun flicker when toggling maximization or
fullscreen on a window in mutter or more sophisicated compositors
and WMs.
What happens is that the client want so go maximized, so we
calculate the size that we want the window to resize to (640x480),
and then add on its margins to find the buffer size (+10 = 660x500),
and then send out a configure event for that size. The client
renders to that size, realizes that it's maximized, and then
says "oh hey, my margins are actually 0 now!", and so the compositor
has to send out another configure event.
In order to fix this, make the the configure request correspond to
the window geometry we'd like the window to be at. At the same time,
replace set_margin with set_window_geometry, where we specify a rect
rather than a border around the window.
Currently, there's a race condition. When resizing from the left, and
a client attaches a buffer after the resize ends, you suddenly see the
buffer jump to the right, because the resize ended while multiple
attaches were in-flight. Making resize a state can fix this, as the
server can now know exactly when the resize ended, and whether a commit
was before or after that place.
We don't implement the correct tracking in this commit; that's left as
an exercise to the reader.
Additionally, clients like terminals might want to display resize popups
to display the number of cells when in a resize. They can use the hint
here to figure out whether they are resizing.
The states system, so far, has been a complicated mix of weird APIs
that solved a real race condition, but have been particularly ugly
for both compositors and clients to implement.
It's a confusing name that comes from the ICCCM. The ICCCM is best
forgotten about.
With the addition of the potential new "transient" role meaning a
parent-relative toplevel like a long-lived popup, used for e.g.
tooltips, the set_transient_for name will become even more confusing.
'close' is more consistent with the purpose of the event than
'delete', and it is also c++ friendly, since 'delete' is a keyword.
Reviewed-by: Jasper St. Pierre <jstpierre@mecheye.net>
Rather than require that the client implement two methods for every state,
simply have one global request, change_state, and one global event,
request_change_state.
Use a static assert to catch mismatch between implementation and
interface version. Fix window.c to not use XDG_SHELL_VERSION_CURRENT,
which will fail to catch version mismatches. The implementation version
must updated manually when the implementation is updated to use the new
interface.
Responsivenes is a per-client thing so we move the ping/pong functionality
to xdg_shell. Having this per-window was carries over from the EWMH
protocol, where the WM has no other way to do this. In wayland, the
compositor can directly ping the client that owns the surface.
This is used to figure out the size of "invisible" decorations, which we'll
use to better know the visible extents of the surface, which we can use for
constraining, titlebars, and more.
This is equivalent to WM_DELETE_WINDOW request under X11, or equivalent
to pressing the "close" button under CSD. Weston currently doesn't have
a compositor-side way to close the window, so no new code is needed on
its side.
xdg_shell is a protocol aimed to substitute wl_shell in the long term,
but will not be part of the wayland core protocol. It starts as a
non-stable API, aimed to be used as a development place at first, and
once features are defined as required by several desktop shells, we can
finally make it stable.
It provides mainly two new interfaces: xdg_surface and xdg_popup.
The xdg_surface interface implements a desktop-style window, that can be
moved, resized, maximized, etc. It provides a request for creating
child/parent relationship, called xdg_surface.set_transient_for.
The xdg_popup interface implements a desktop-style popup/menu. A
xdg_popup is always transient for another surface, and also has implicit
grab.
Jasper St. Pierre
Boyan Ding
Giulio Camuffo
Kristian Høgsberg
Rafael Antognolli