Currently, we will notify the display about a new window being created
during the constructed phase of the GObject. During this time,
property-change notifications are frozen by GObject, so we'll emit a few
::notify signals only after the window-created signal, although
the actual property change happened before that.
This caused confusion in gnome-shell code where a notify::skip-taskbar =
true emission was seen when the property already was true inside a
window-created handler before.
In order to fix that that, we notify the window creation
post-construction
of the GObject on GInitable.init vfunc
Details
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6119#note_1598983
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6119
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2703>
Fullscreen Wayland toplevel surfaces don't need to respect the
configured size in which case it should be shown centered on the monitor
with a black background. The black background becomes part of the window
geometry.
The surface container is responsible for correctly culling the surfaces
and making sure the surface actors are removed from the actor tree to
avoid destroying them.
The window actor culling implementation assumes all surfaces to be direct
children of said actor. The introduction of the surface_container actor
broke that assumption. This implements the culling interface in
MetaWindowActorWayland which is aware of the actor surface_container and
fullscreen state.
v2: Fix forwarding culling to surface even if there is a background.
v2: Don't alter passed geometry.
v2: Update window geometry code documentation to reflect these changes.
v2: Only use constrained rect if we're acked fullscreen.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2338>
This is helpful to know what current state a window actually have, in
contrast to the state in MetaWindow (e.g. MetaWindow::fullscreen) which
is the intended state, be it current or not yet so.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2338>
First make sure we call 'move_resize()' in all cases where the size or
position can change, then move the updating of the buffer rect to the
same place as we update the frame rect. This means keeping track of
surface size changes, in addition to geometry changes, and calling
finish_move_resize() whenever any of those changes, in addition to
acknowledged configurations.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2338>
When a window configuration is constructed for a Wayland surface it
contains a position, size and a scale. The scale is the geometry scale
for the configuration, i.e. before the size is sent the passed dimension
is divided with the passed scale.
When moving between monitors with different scales, if we use the
existing geometry scale, this means we will send a configure event with
incorrect dimensions. Fix this by calculating the scale used in the
configuration given the rect we're configuring with as this will mean
the correct size will be sent to the client.
v2: Removed the fullscreen condition. Don't know why it was added to
begin with.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2338>
There were some magic conditions that decided when
meta_window_constrain() was to be called or not. Reasoning about and
changing these conditions were complicated, and in practice the caller
knows when constraining should be done. Lets change things by adding a
'constrain' flag to the move-resize flags that makes this clearer. This
way we can, if needed, have better control of when a window is
constrained or not without leaking that logic into the generic
to-constrain-or-not expression.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2338>
If the window didn't have a size, it would still have a monitor, and
when we are asked to update, we must update, as the old monitor might
not be kept around, leaving us vulnerable to use after free.
Avoid not updating the monitor by using the stored IDs (preferred, or
previous) to find suitable logical monitors, with the primary monitor
being the last fallback unless we're completely headless.
This fixes the assert
!window->monitor ||
g_list_find (meta_monitor_manager_get_logical_monitors (monitor_manager),
window->monitor)
in meta_window_update_for_monitors_changed() being hit when a Wayland
window has been created, but not mapped, when a hotplug happens.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2554>
The function finds a suitable logical monitor given the window
rectangle; this wasn't all that clear from the name
"calculate_main_logical_monitor".
This is in preparation for finding a new logical monitor using things
other than the geometry of the window.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2554>
Prior to 67033b0a mutter was accidentally including sizes for
configurations that were just focus state changes. This was not leading
to any known problems on the client side, but it was causing issues in
mutter itself when detecting whether a resize originated from the client
or the server.
Not including sizes in focus change configurations anymore however
revealed a bug in gtk. It was storing the window size when in a fixed
size mode (tiled/maximized/fullscreen), but not on any other server side
resizes. It was then restoring this stored size whenever there was a new
configuration without a size while in floating mode, i.e. the focus
change configurations generated by mutter after 67033b0a.
This change now addresses the issue 67033b0a was fixing in a way that
restores the previous behavior of always including the size whenever
sending a configuration.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2091
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2238>
This implements the new 'bounds' event that is part of the xdg_toplevel
interface in the xdg-shell protocol. It aims to let clients create
"good" default window sizes that depends on e.g. the resolution of the
monitor the window will be mapped on, whether there are panels taking up
space, and things like that.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2167>
We'd guess the initial monitor before it was actually calculated by
looking at the initial geometry. For Wayland windows, this geometry was
always 0x0+0+0, thus the selected monitor was always the primary one.
This is problematic if we want to provide initial more likely
configurations to Wayland clients. While we're not doing that yet, it'll
be added later, and this is in preparation for that.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2167>
The previous code was trying to detect client resizes by only
considering resizes without any pending configurations as client
resizes. There can however be pending configurations that do not involve
resizing, such as ones triggered by state changes. These may also stay
unacknowledged by the client until the next size change. This was
causing client resizes after showing the window (and therefore changing
its status to focused) to not be detected as client resize.
Fix this by checking whether the queue has any configuration with size
changes rather than just whether it is empty.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2023
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2103>
meta_window_wayland_finish_move_resize() is called for both, finishing
a resize that has been requested through/by mutter and for resizes
directly done by the client. This introduces a CLIENT_RESIZE flag to
differentiate the former from the latter. Having this distinction is
required to know what the last requested size by either the client or
mutter is while ignoring older requests that might only have been
applied now.
This excludes client resizes when there are still pending
configurations, because the resize is known to be only temporary.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2066>
When the MetaWindow resize machinery for toplevels ended up in the
Wayland window implementation, we tried to avoid configuring
not-yet-mapped windows that just had its zero sized dimension pass
through the constraint machinery, resulting in a 1x1 sized window.
If we'd properly set up the min size metadata earlier, that 1x1 would
likely be the minimum size set of a window, which makes things harder to
predict when peeking at side effects.
However, what the side effect peeking intends to do, as documented in
the comment, was to figure out when the client hadn't committed any
buffer yet, i.e. during the initial map, and in those cases avoid
sending that nasty 1x1 size, resulting in silly window sizes. A more
robust way to detect this is instead checking when we shouldn't really
try resize things our own way, and in those cases early out as was done
before.
This means that, for a yet to me mapped window, we only ever want to
send an initial non-zero configuration when 1) it's initially maximized,
2) initially fullscreen, or 3) initially tiled in any way, as those are
the situations where the compositor is the one deciding the size.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1912>
When deciding if `configure` event should be sent,
`meta_window_wayland_move_resize_internal` compares requested window size
with `window->rect` size. However, `window->rect` is only updated when `commit`
is received. So the following sequence produces incorrect result:
1. a window initially has size `size1`
2. `move_resize_internal` is called with `size2`. `configure` is sent
3. `move_resize_internal` is called with `size1` to restore original size,
but `commit` for `size2` haven't arrived yet. So `window->rect` still has size
`size1`, and thus new `configure` is not sent
4. `commit` for `size2` arrives, window changes size to `size2`
Expected window size in the end: `size1`
Actual: `size2`
To fix the issue, take size from pending `configure` events into account.
Fixes https://gitlab.gnome.org/GNOME/mutter/-/issues/1627
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1755>
X11 clients can use different models of input handling, of which some
may not result focus being set synchronously.
For such clients, meta_focus_window() will not change the focus itself
but rely on the client itself to set the input focus on the desired
window.
Add a new MetaWindow API to check when dealing with such a window.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1716>
When (un)maximizing, (un)fullscreening, the move/resize action is
flagged with 'ACTION_MOVE' and 'ACTION_RESIZE' , while e.g.
'appears-focus' does not.
When a client misbehaved and didn't immediately reply to a configure
request with a commit with the corresponding ack_configure, the
following commit would trigger a oddly timed move, making the window
appear to move back to a previous position.
Avoid this issue by only carrying over the target window position if the
configuration actually contained a new position.
We cannot only rely on the flags however, as e.g. a new position should
be respected during interactive resize, even though only 'ACTION_RESIZE'
is passed in such scenarios.
Do the same for the size, except if the window state dictates that the
size is fixed to a certain size, e.g. being fullscreen or maximized.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1445>
Commit 8bdd2aa7 would offset the window position by the difference
between the configured window size and the committed size from the
client to prevent the window from drifting while resizing.
This, however, did not take into account the actual geometry scale, so
when using any scale greater than 1, the window would rapidly drift away
due to that offset.
In order to solve this, we need to make sure we store away the pending
window configuration in the stage coordinate space, in order to not
loose precision. When we then calculate the offset given the result from
the client, it'll use the right scalars, while before, one scalar was in
surface coordinates, while the other in stage coordinates.
https://gitlab.gnome.org/GNOME/mutter/-/issues/1490
Implements the "prior window window geometry dimensions" as described in
the documentation of 'xdg_toplevel' request 'unset_maximized':
"If available and applicable, the compositor will include the window
geometry dimensions the window had prior to being maximized in the
configure event."
and 'unset_fullscreen':
"The compositor may include the previous window geometry dimensions in
the configure event, if applicable."
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/792.
When we resize a window we send it configure requests with size
suggestion. Some clients, e.g. gnome-terminal will limit its size to a
discrete set given the font size resulting in the size often not being
respected completely, but used as a hint to find a size as large as
possible but not larger than the configured size.
When doing an interactive resize dragging the right or top side of a
window, this caused issues with the configured window size not matching
the one used by the client, as the configured position wouldn't be
correct for the actual size. Fix this by offsetting the position given
the size mismatch offset, making the position again in sync with the
size.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1447https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1477
We only did this if we weren't currently doing an interactive resize,
but since the finish_move_resize() is not the actual interactive resize
but the acknowledgment of the configure event that was emitted as a
result, we shouldn't limit ourself to the same flags used during resize.
This fixes temporarly "stuck" position of attached modal dialogs while
they are being resized.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1163https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1446
When resizing a window interactively, we'll set a grab operation and a
grab window, among other things. If we're resizing (including setting
initial size, i.e. mapping) another window, that didn't change position,
don't use the gravity of the grab operation when resizing our own
window.
This fixes an issue with jumpy popup position when moving a previously
mapped gtk popover.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/999
We send configure events for state changes e.g. for `appears-focused`,
etc. What we don't want to do is to do this for popup windows, as in
Wayland don't care about this state.
When the focus mode was configured to "sloppy focus" we'd get
`appears-focused` state changes for the popup window only by moving the
mouse cursor around, and while a popup may care about focus, it does not
care about related appearance, as there is no such state in xdg_popup.
What these state changes instead resulted in was absolute window
configuration events, intended for toplevel (xdg_toplevel) windows. In
the end this caused the popup to be positioned aginst at (0, 0) of the
parent window, as the assumptions when the configuration of the popup
was acknowledged is that it had received a relative position window
configuration.
Fix this by simply ignoring any state changes of the window if it is a
popup, meaning we won't send any configuration events intended for
toplevels for state changes. Currently we don't have any way to know
this other than checking whether it has a placement rule. Cleaning up
MetaWindow creation is left to be dealt with another day.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/1103https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1122
If we don't force the placement, we enter the constrain machinery with
the position (0, 0), meaning we always get the "current work area" setup
to correspond to whatever logical monitor was at that position.
Avoid this by doing the same as "meta_window_force_placement()" and set
"window->calc_placement" to TRUE while move-resizing, causing the
move-resize to first calculate the initial position.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/1098https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1110
This commit completes the implementation of `xdg_wm_base` version 3,
which introduces support for synchronized implicit and explicit popup
repositioning.
Explicit repositioning works by the client providing a new
`xdg_positioner` object via a new request `xdg_popup.reposition`. If the
repositioning is done in combination with the parent itself being
reconfigured, the to be committed state of the parent is provided by the
client via the `xdg_positioner` object, using
`xdg_positioner.set__parent_configure`.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/705
This commits adds support on the MetaWindow and constraints engine side
for asynchronously repositioning a window with a placement rule, either
due to environmental changes (e.g. parent moved) or explicitly done so
via `meta_window_update_placement_rule()`.
This is so far unused, as placement rules where this functionality is
triggered are not yet constructed by the xdg-shell implementation, and
no users of `meta_window_update_placement_rule()` exists yet.
To summarize, it works by making it possible to produce placement rules
with the parent rectangle a window should be placed against, while
creating a pending configuration that is not applied until acknowledged
by the client using the xdg-shell configure/ack_configure mechanisms.
An "temporary" constrain result is added to deal with situations
where the client window *must* move immediately even though it has not yet
acknowledged a new configuration that was sent. This happens for example
when the parent window is moved, causing the popup window to change its
relative position e.g. because it ended up partially off-screen. In this
situation, the temporary position corresponds to the result of the
movement of the parent, while the pending (asynchronously configured)
position is the relative one given the new constraining result.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/705
MetaGravity is an enum, where the values match the X11 macros used for
gravity, with the exception that `ForgetGravity` was renamed
`META_GRAVITY_NONE` to have less of a obscure name.
The motivation for this is to rely less on libX11 data types and macros
in generic code.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/705
A placement rule placed window positions itself relative to its parent,
thus converting between relative coordinates to absolute coordinates,
then back to relative coordinates implies unwanted restrictions for
example when the absolute coordinate should not be calculated againts
the current parent window position.
Deal with this by keeping track of the relative position all the way
from the constraining engine to the move-resize window implementation.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/705
To organize things a bit better, put the fields related to the placement
rule state in its own anonymous struct inside MetaWindow. While at it,
rename the somewhat oddly named variable that in practice means the
current relative window position.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/705
After popup placement rules have gone through the constraints engine has
ended up resulting in an actual move, pass the window configuration down
the path using relative coordinates, as that is what the next layer
(xdg-shell implementation) actually cares about.
In the future, this will also be helpful when the configured position is
not against the current state of the parent.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/705
meta_window_wayland_finish_move_resize() inhibited window moves to be
finished if there was a resize grab active at the time, in order to
handle window resizing. Change this to only affect the grabbed window
itself, so that e.g. a popup can be positioned according to a pending
configuration while there is an active resize grab.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/705
The acked configuration is removed from the pending configuration list
by acquire_acked_configuration(), but finish_move_resize() does not free
the data after applying the configuration.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1020
This changes how asynchronous window configuration works. Prior to this
commit, it worked by MetaWindowWayland remembering the last
configuration it sent, then when the Wayland client got back to it, it
tried to figure out whether it was a acknowledgment of the configuration
or not, and finish the move. This failed if the client had acknowledged
a configuration older than the last one sent, and it had hacks to
somewhat deal with wl_shell's lack of configuration serial numbers.
This commits scraps that and makes the MetaWindowWayland take ownership
of sent configurations, including generating serial numbers. The
wl_shell implementation is changed to emulate serial numbers (assuming
each commit acknowledges the last sent configure event). Each
configuration sent to the client is kept around until the client one. At
this point, the position used for that particular configuration is used
when applying the acknowledged state, meaning cases where we have
already sent a new configuration when the client acknowledges a previous
one, we'll still use the correct position for the window.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/907
The intention of meta_window_wayland_move_resize() is to finish a
move-resize requested previously, e.g. by a state change, or a
interactive resize. Make the function name carry this intention, by
renaming it to meta_window_wayland_finish_move_resize().
https://gitlab.gnome.org/GNOME/mutter/merge_requests/907
While most of the code to compute a window's layer isn't explicitly
windowing backend specific, it is in practice: On wayland there are
no DESKTOP windows(*), docks(*) or groups.
Reflect that by introducing a calculate_layer() vfunc that computes
(and sets) a window's layer.
(*) they shall burn in hell, amen!
https://gitlab.gnome.org/GNOME/mutter/merge_requests/949
Geometry scale is applied to each surface individually, using
Clutter scales, and not only this breaks subsurfaces, it also
pollutes the toolkit and makes the actor tree slightly too
fragile. If GNOME Shell mistakenly tries to set the actor scale
of any of these surfaces, for example, various artifacts might
happen.
Move geometry scale handling to MetaWindowActor. It is applied
as a child transform operation, so that the Clutter-managed
scale properties are left untouched.
In the future where the entirety of the window is managed by a
ClutterContent itself, the geometry scale will be applied
directly into the transform matrix of MetaWindowActor. However,
doing that now would break the various ClutterClones used by
GNOME Shell, so the child transform is an acceptable compromise
during this transition.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/409
When we're unfullscreening, we might be returning to a window state that
has its size either managed by constraints (tiled, maximized), or not
(floating). Lets just pass the configure size 0x0 when we're not using
constrained sizes (i.e. the window going from being fullscreen to not
maximized) and let the application decide how to size itself.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/638https://gitlab.gnome.org/GNOME/mutter/merge_requests/621
Code underneath seems to handle errors properly, or be x11-agnostic
entirely, this is apparently here to save a few XSync()s on X11. Just
drop this windowing dependent bit to make things cleaner.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/420
In all places (including src/wayland) we tap into meta_x11_display* focus
API, which then calls meta_display* API. This relation is backwards, so
rework input focus management so it's the other way around.
We now have high-level meta_display_(un)set_input_focus functions, which
perform the backend-independent maintenance, and calls into the X11
functions where relevant. These functions are what callers should use.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/420
