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.
Once we've updated the window state and scheduled a resize, we know that
the next frame we send to the compositor will match the configured state.
This means we can just ack the configure immediately and not jump
through hoops to try to do it from the redraw stage.
As the protocol says, the states determine how the width and height
arguments should be interpreted, so it makes logical sense to do the
interpretation after.
Add a new state_changed_handler callback to the window to know when the
window has changed state; the terminal will use this to know when the
window started and ended its resize operation, and modify the terminal's
titlebar accordingly.
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.
Toytoolkit was not designed to handle input from subsurfaces and
instead it expects subsurfaces to have an empty input region. That way
input events for subsurfaces are generated on the main surface and
there is no need to convert coordinates before reporting the event to
the user.
However it is possible that a subsurface has a non-empty input region,
but in that case those events aren't properly processed. The function
window_find_widget() assumes the coordinates are in the main surface
coordinate space, and ends up chosing the wrong widget.
This patch changes the input code to completely ignore input events from
subsurfaces. This option was chosen instead of ensuring that the input
region on those surfaces is always empty since there's no enforcement
that a subsurface should completely overlap with the main surface. If
an event happens in the area of the surface that doesn't overlap, the
event could cause a completely unrelated surface to be picked.
https://bugs.freedesktop.org/show_bug.cgi?id=78207
Ideally, we'll update the key event handling to deliver events to widgets,
but in the meantime, just blocking key event delivery while a grab is
active goes a long way.
It looks like the handler for frame events from the wl_touch interface for
widgets may have been erroneously copied from the cancel handler so that it
removes all handlers as they are processed. I don't think this makes much sense
for the frame event. This was stopping the panel icons from being pushable with
touch events when using libinput since commit 1679f232e5. All that commit
does it make it start sending the frame events.
When adding a subsurface (to display a tooltip) in toytoolkit,
we now get the parent window surface type (SHM or EGL) and
define the new surface type as the same.
This fixes crashes with tooltips in cases like having
Cairo-EGL available but running the X11 compositor.
Signed-off-by: Manuel Bachmann <manuel.bachmann@open.eurogiciel.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.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.
Clients that need to be redrawn when the focus changes do that by
listening to focus_changed and scheduling a redraw.
This was causing unnecessary redraws in the clients, as could be
easily seen by changing focus on weston-flower.
Signed-off-by: Emilio Pozuelo Monfort <emilio.pozuelo@collabora.co.uk>
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.
When we set the fullscreen flag, we have to wait for the corresponding
configure event and then attach a buffer of that size to indicate
that we've successfully gone fullscreen/maximized.
Without this patch, we can schedule a redraw and go through with it after
setting maximize/fullscreen and end up attaching a buffer of the wrong size.
In practice, what happens is that pressing the maximize button triggers
setting maximized, but also triggers a redraw to paint the maxmize button.
Without this change, repainting the button triggers a repaint that attaches
the same size buffer immediately.
https://bugs.freedesktop.org/show_bug.cgi?id=71927
xdg_shell changes this around so that they are flags on the remote
object itself, not separate surface types. Move to a system where
we calculate the state from the flags ourselves and set the appropriate
wl_shell_surface type.
When we port to xdg_shell, we'll drop these flags and simply sync
on the client.
Transient windows, at least not as they are today, don't exist in
xdg_shell. Subsurfaces allow for specially placed surfaces relative
to a window, so use these instead.
