Use the meta_window_is_fullscreen() API instead of accessing the
fullscreen field of the MetaWindow structure directly.
This is both a (small) cleanup and preparation work for the next commit.
No function change (intended).
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4076>
In acbb14f34bc8fee14e77db3c100e5d116d8e3d60, we have dropped the
is_client_decorated except it was still being used by gnome-shell
to adjust the window coordinates in case it is using server side
decoration.
Instead of re-adding the same function, expose a new function that
takes care of getting the whole client area while taking into account
SSD for X11 clients.
Helps https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7984
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4087>
To avoid mostly going through struct fields in macros as we might soon
move those first to a WindowConfiguration & maybe even make the window
struct private with time.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4111>
Allow scale-aware Xwayland clients to scale by an integer scale
themselves, instead of letting them render them at 1x scale and then
scaling up the texture, making it look blurry.
When monitor framebuffers are scaled, this special cases Xwayland and
sends output regions in a way that Xwayland think everything is N times
as large as the logical region, where N is the ceil of the max monitor
scale.
This is done by introducing a "stage" vs "protocol" coordinate space for
X11, where the "protocol" coordinate space is "stage" multiplied by a
scaling factor.
Xwayland thus will have its own "effective scale", sent via
wl_output.scale. The effective Xwayland scale is also used for the
internal MetaWaylandSurface scale internally, unless there is a viewport
dst size set on the same surface, in which case the scale is still set
to 1, to not interfere with wp_viewport semantics.
We're guarding this behind a new experimental feature
"xwayland-native-scaling", which can only come into effect when enabled
together with "scale-monitor-framebuffer".
[v2]:
Move stage_to_protocol/protocol_to_stage to generic window class.
This means parts that aren't aware of any windowing system specific
logic, only that coordinates originate from there for a given window,
can still get their coordinates properly handled.
In particular, this means coordinates from IBus that originates from the
client, can be scaled properly when that client is using X11.
Also make them properly introspected.
[v3]:
Split up coordinate transform API.
Make it one that takes a MtkRectangle, and another that takes a point.
This means the rounding strategy becames explicit when transforming a
point, while when it's a rectangle, it's still always "grow".
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3567>
Toplevels get the main monitor from their MetaWindow and have no main
monitor when the toplevel is not mapped.
Subsurfaces get the main monitor from their parent surface.
DnD and cursors get the main monitor from the current cursor position no
matter if the cursor is actually being shown or not.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3941>
Having an always-on-top window affects focus granting logic if the
to be showing window overlaps with any of them. Instead of triggering
the focus denying logic if a new window ever so slightly touches an
always-on-top window to only triggering if it's covered more than 60% by
always-on-top windows.
This is intended to make using always-on-top windows a bit less annoying
and not cause as many unintended focus-on-map denials.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3879>
When we show a window, we'll check if it overlaps with an existing
always-on-top window with the intention to deny focus. However, we did
this potentially before having placed the window, meaning we effectively
checked as if it was placed at (0, 0), which created unexpected results.
Instead check the overlap state after placing. A window placement test
case is added to verify this works as expected.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3879>
Replace a boolean argument and a temporary MetaWindow struct field with
a `MetaPlaceFlag` passed where relevant. This includes
`meta_window_move_resize_internal()` and `meta_window_constrain()`, as
placement may happen during constraining, and also
`meta_window_force_placement()`.
The struct field (denied_focus_and_not_transient) was only ever set in
meta_window_show(), before meta_window_force_placement(), and
immediately unset as a side effect of that. In .._show() we'll always
force placement if the window wasn't already placed, and in
meta_window_constrain(), we'd only ever call meta_window_place() if the
window wasn't already placed, meaning the variable would only ever be
relevant during `meta_window_show()`. Having it as a flag makes that
relationship and temporary state clearer.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3879>
The function checking whether a 'always-on-top' window covers the
showing window now has that in the name, to make it more obvious. That
function was also changed to use the more common way of iterating a
list, and now uses auto cleanup pointers for the list.
The condition itself was updated to follow the current coding style.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3879>
This avoids the following critical warning happening sometimes when a
Wayland client exits taking all its window with it in an arbitrary
order:
CRITICAL: meta_window_set_stack_position_no_sync: assertion 'window->stack_position >= 0' failed
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3870>
When a transient window becomes transient, check if the parent is
sticky, and if it is, make the transient sticky as well. This handles
situations where e.g. a utility dialog (such as search and replace) is
opened on a sticky window, also making the utility dialog sharing the
same stickyness state.
This is also more in line with the semantics of making a window sticky,
where transient would implicitly become sticky as a side effect.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3870>
If a transient window is sticky (visible on all workspaces) and it gets
activated, we'd call move_worskpace() which would effectively unstick
it, which is rather unexpected. It'd also effectively unstick its parent
as well, due to moving a transient window also moves its descendants and
ascendants.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3870>
Instead use an abstract "logical monitor id" that is generated from the
logical monitor. Instead of using low level numbers from the mode
setting devices, use either data from the EDID, or the connector, if the
EDID is not useful.
This should help with windows remembering monitor positions when the
same monitor reappears but with another mode setting device ID.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3753>
That was only there to force updating MetaFrame's bounds
but that is something that is already updated in
MetaWindowX11.move_resize_internal. So just drop all of that
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3254>
When a client resizes on its own, make sure the new size is passed
through the window constraints machinery directly, to trigger any
potential window management rule that might apply.
Fix a couple of tests to make use of this behavior by introducing a new
'wait_size' command that waits until a window has been resized to a
expected size.
This replaces the fix introduced in 0e736af301 ("window: Ensure
constraints after a Wayland client resize").
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3700>
Starting the timeout to move from hidden to suspended before the window
is mapped means we don't have a previous window configufration which we
need to get the new window configuration with the suspended state.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3731>
Instead of initializing to 'suspended', which will send the `SUSPENDED`
xdg_toplevel state, set it to hidden at first. If the window is placed
on an inactive workspace, it'll eventually enter the 'suspended' state,
but will have had some time in non-suspended state to get map, even if
not visibly.
This fixes inital suspended state when mapping a window maximized.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3229
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3475>
This, in contrast to meta_window_should_be_showing() reports whether a
window should be showing despite not being showable. This is useful to
know the intended visibility state that should happen in the immediate
future.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3475>
When the monitors change meta_window_update_for_monitors_changed is
called which is responsible for updating window->monitor. It however can
go through the entire window placement and constraint machinery before
it's able to do so. In this period window->monitor points to the old
MetaMonitor where the monitor number doesn't reflect the index into the
MonitorManager anymore.
Avoid relying on the window->monitor->number and go through the Monitor
directly.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3402
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3691>
When multiple configure requests sent to the wayland client within a sort period, maximized windows may end up in wrong position and cover struts. To avoid this, queue a resize when the resize event sent by the wayland client results a changed size or position to ensure that the final size and position will be always right.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3601>
meta_window_handle_ungrabbed_event() triggers the show of the window menu in
gnome-shell via meta_window_show_menu() on hold of Meta + right mouse button
click.
Since meta_display_handle_event() was refactored lately and now forwards a
lot more events to Clutter (including the one triggering the window menu),
gnome-shell now sees this event after the menu has opened, figures that the
source-actor is outside of the menu, and immediately closes the menu again.
This is the correct behavior from the PopupMenuManager on the gnome-shell
side, it is the responsibility of the event handler that opens the menu (aka
meta_window_handle_ungrabbed_event()) to return CLUTTER_EVENT_STOP and stop
event propagation.
So fix this issue by adding a return value to
meta_window_handle_ungrabbed_event() and stopping event propagation in case
the event opened the window menu.
While at it, also return CLUTTER_EVENT_STOP for events triggering window
drags, so we can drop the extra check for that in
meta_display_handle_event().
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3623>
