This addresses the following race condition:
1. Window+MetaFrame are created non-fullscreen, _MUTTER_FRAME_EXTENTS
is initialized through widget measuring, accounting for frame.
2. Window and MetaFrame become fullscreen.
3. MetaFrameContent gets first size allocation, already fullscreen.
4. Borders were initialized to 0,0,0,0, become set to 0,0,0,0 correctly
reflecting fullscreen, however notify::borders is not emitted.
5. _MUTTER_FRAME_EXTENTS stays accounting for the frame extents.
It sounds sensible to have the borders initialized to a meaningful value,
so account for the first time the border would be set due to the content
being (re)sized, and let this first value trigger notify::borders resulting
in _MUTTER_FRAME_EXTENTS updates.
Since all later _MUTTER_FRAME_EXTENTS changes happen through content
resizes, we only have to cater for this initial handover between the
frame/content initialization paths done through widget measuring and
the later paths done through MetaFrameContent resizes.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2937
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3476>
This small X11 client takes care of creating frames for client
windows, Mutter will use this client to delegate window frame
rendering and event handling.
The MetaWindowTracker object will keep track of windows created
from other clients, and will await for _MUTTER_NEEDS_FRAME property
updates on those (coming from Mutter), indicating the need for a
frame window.
This process is resilient to restarts of the frames client, existing
windows will be queried during start, and the existence of relevant
properties checked. Mutter will be able to just hide/show
SSD-decorated windows while the frames client restarts.
The frames are created through GTK4 widgets, the MetaWindowContent
widget acts as a replacement prop for the actual client window,
and the MetaFrameHeader wraps GtkHeaderBar so that windows can be
overshrunk, but otherwise a MetaFrame is a 100% true GTK4 GtkWindow.
After a frame window is created for a client window, the
_MUTTER_FRAME_FOR property will be set on the frame window,
indicating to mutter the correspondence between both Windows.
Additionally, the pixel sizes of the visible left/right/top/bottom
borders of the frame will be set through the _MUTTER_FRAME_EXTENTS
property, set on the frame window.
In order to make the frame window behave as the frame for the
client window, a number of properties will be tracked from the
client window to update the relevant frame behavior (window title,
resizability, availability of actions...), and also some forwarding
of events happening in the frame will be forwarded to the client
window (mainly, WM_DELETE_WINDOW when the close button is clicked).
Other than that, the frames are pretty much CSD GTK4 windows, so
window drags and resizes, and window context menus are forwarded for
the WM to handle.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2175>
