The macro used to call into a bunch of other macros so let us turn it
into a single function.
This would simplify things for the next commit that puts the MetaGroup
usage behind a X11 ifdef
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3555>
The following commits will make it possible to pass a NULL window to
display_handle_window_enter/leave to represent the cursor entering the
desktop. This means it can't be a method of the window class anymore.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3258>
Commit 3bfcb6d1 fixed the check for tiling via keybindings, but
ignored a subtle edge case when tiling with the pointer: The
monitor used for tiling is the monitor with the pointer, which
is not necessarily the one that contains the largest part of the
window.
That is, the correct monitor to check against depends on the
context where the function is called. We can either figure
it out automatically via the current window drag, or make it
a parameter.
The latter is clearer, because the callers already decide which
monitor to use for tiling anyway.
Fixes: 3bfcb6d1b9 ("window: Fix portrait orientation check for tiling")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3248>
The 'suspend state' is meant to track whether a window is likely to be
visible any time soon. The hueristics for this are as follows:
* If a window is hidden, it will enter the 'hidden' state.
* If a window is visible, and unobscured, it will enter the 'active'
state.
* If a window is visible, but obscured by another window, it will enter
the 'hidden' state.
* If there is a mapped clone of a window, it will enter the 'active'
state.
* If the window has been in the 'hidden' state for 3 seconds, it will
enter the 'suspended' state.
This will eventually be communicated to Wayland clients so that they can
change their behaviour to e.g. save power.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3019>
When selecting the default focus window, is_focusable() was not
considering the new conditions for whether a window should be shown or
hidden that were added to meta_window_should_be_showing() in 39942974.
As a result the default focus window could end up a window already
hidden or hidden once meta_window_flush_calc_showing() is called by
meta_window_focus() when focusing the default window. This would cause
meta_window_focus() to fail, which is an issue if it prevents us from
unfocusing a window when it is getting unmanaged.
Fixes: 399429742 ("x11: Integrate frames client into Mutter")
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2644
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2962>
Since MetaWindowDrag took a lot of this code to handle window drags
internally with less interactions with the rest of the stack, this
code in display/window/keybindings is unused.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2683>
Replace the in-process implementation of frames with the external
frames client.
When a client window is created and managed by Mutter, Mutter will
determine whether it is a window that requires decorations and
hint the creation of a frame for it by setting the _MUTTER_NEEDS_FRAME
property on the client window.
After the frames client created a window that has the _MUTTER_FRAME_FOR
property, Mutter will proceed to reparent the client window on the
frame window, and show them as a single unit.
Rendering and event handling on the frame window will be performed by
the external client, Mutter is still responsible for everything else,
namely resizing client and frame window in synchronization, and
managing updates on the MetaWindowActor.
In order to let the frame be managed by the external client, Mutter
needs to change the way some properties are forwarded to the client
and/or frame windows. Some properties are necessary to keep propagating
to the client window only, some others need to happen on the frame
window now, and some others needs to be propagated on both so they
are synchronized about the behavior.
Also, some events that were previously totally unexpected in frame
windows are now susceptible to happen, so must be allowed now.
MetaFrame in src/core/frame.c now acts as the wrapper of foreign
windows created by the frames client, from the Mutter side. Location,
size, and lifetime are still largely in control of Mutter, some
details like visible/invisible borders are obtained from the client
instead (through the _MUTTER_FRAME_EXTENTS and _GTK_FRAME_EXTENTS
properties, respectively).
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2175>
Put the helper to use, in order to lift MetaWindow itself from this
accounting. As a bonus, the data itself now moved to the MetaWindowX11
private struct, since this may only happen with X11 windows (or its
Xwayland subclass).
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2175>
We can land inside meta_window_focus() in the middle of changing the
window workspace, because some signal handler of MetaWorkspace's
"window-removed" signal triggers a focus. This can cause a crash in
`g_assert (link)` when updating the MRU list because we still think
we're on the old workspace when actually we are already removed from
this workspaces MRU list.
To avoid crashes like this, bail out of meta_window_focus() when we're
in the middle of a workspace change.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5368
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2691>
It's a bad idea to have data like this in the middle of a struct, as it
will easily cause everything behind it to be badly aligned and thus
increase memory access times.
So move all those bitfield booleans to the end of the struct.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2691>
With high frequency mouse devices, we would send very many configure
events per each update cycle, which had the end result that some clients
constantly re-allocating and redrawing their buffers far too often, if
they did this in direct response to xdg_toplevel configure events.
Lets throttle the interactive resize updates to stage updates, to avoid
having these clients doing the excessive buffer reallocation.
This also removes some old legacy X11 client resize throttling, that
throttled a bit arbitrarily on 25 resizes a second; it is probably
enough to throttle on stage updates for these clients.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2652>
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>
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>
This will later be used to tell Wayland clients about a size they
shouldn't exceed.
If the window doesn't have a main monitor, this function does nothing
and returns FALSE.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2167>
meta_window_(un)queue() was implemented with global arrays in window.c
that managed MetaLater handle IDs and lists of window queues. In order
to rely less on scattered static variables and making it clearer that
we're dealing with per display window management and not something
specific to a single window, move the window resize/calc-showing queue
management to MetaDisplay.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2264>
It's still used by e.g. GNOME Shell to produce fallback icons for X11
applications that doesn't come with a .desktop file. Geometry stays in
the generic class because it's used for minimize animations and is
configured by the panel (e.g. the one in gnome-shell-extensions).
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2264>
Change some things in these "app is alive" checks:
- The dialog timeout is separated from the ping timeout, in order
to show it again at a constant rate after dismissing, despite in
flight pings. It still shows immediately after the first failed
ping.
- As we want to tap further into is-alive logic, MetaWindow now
made it a property, that other places in code can fetch and
subscribe.
- Motion events trigger ping (as long as there was none other in
flight for the same window), and are counted between ping and
pong, in order to preemptively declare the window as not alive
before there is trouble with event queues being overflown.
This results in a separate logic between "the application does
not respond" and "we are showing the close dialog" so that the
former may get triggered independently.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2122>
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>
Currently the only way to get cgroup for a MetaWindow is to get it's
PID and perform a bunch of file accesses and string manipulations.
This is especially not feasible if we want to get the cgroup every
time a MetaWindow has gained or lost focus.
A solution to this is to cache the GFile for a cgroup path.
The creation and access of this GFile is handled by
`meta_window_get_unit_cgroup` function.
`meta_window_unit_cgroup_equal` is a utility function which allows
us to compare whether two MetaWindows belong to the same cgroup.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1960>
Makes workspace transitions in gnome-shell look more seamless, since
both outgoing and incoming workspace have focused windows.
This is only done for click focus mode, since it's not known which
window would be focused for the other modes.
Track the state and recompute it when it changes, to avoid redrawing
the windows needlessly.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/850>
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>
We will use a dedicated variable when transitioning to/from fullscreen state
and leave the previously used 'saved_rect' exclusively for transitioning
between floating and maximized state.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/801
