In profilers with a timeline or flame graph views it is a very common
scenario that a span name must be displayed in an area too short to fit
it. In this case, profilers may implement automatic shortening to show
the most important part of the span name in the available area. This
makes it easier to tell what's going on without having to zoom all the
way in.
The current trace span names in Mutter don't really follow any system
and cannot really be shortened automatically.
The Tracy profiler shortens with C++ in mind. Consider an example C++
name:
SomeNamespace::SomeClass::some_method(args)
The method name is the most important part, and the arguments with the
class name will be cut if necessary in the order of importance.
This logic makes sence for other languages too, like Rust. I can see it
being implemented in other profilers like Sysprof, since it's generally
useful.
Hence, this commit adjusts our trace names to look like C++ and arrange
the parts of the name in the respective order of importance.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3402>
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>
The shell might raise and make windows recent for another workspace when
an app gets activated on another workspace. Making the windows only
recent on the current workspace thus results in inconsistent focus when
another window of the same app is closed.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3315>
Assigning the corresponding stack layer of DESKTOP windows is
currently X11 specific, because there is no way for wayland
clients to set the DESKTOP window type.
This is about to change, so move the code to the generic layer
handling.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3305>
Focus follows mouse is meant to avoid focusing windows that happened
to pop up under the pointer, e.g. due to mapping, workspace changes,
etc... On X11, this has been done since ancient times through a
moderately complex synchronization mechanism, so mutter would know
to ignore crossing events caused on those situations.
This mechanism is much prior to XInput 2 though, where we may know
this in a more straightforward way: If the sourceid of the crossing
event is a logical pointer (i.e. equals deviceid), the crossing event
was triggered logically, and not through user input.
Perform this simpler check, and drop the existing mechanism to
ignore logically induced crossing events.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3267>
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>
Use work area from the monitor that the window is currently on to
determine if tiling should be allowed.
Window tiling is disabled for monitors with portrait orientation, but
the work area we use to detect portrait orientation is taken from the
monitor that currently has the mouse pointer.
This works fine for edge tiling using the mouse, but this is broken when
using keybindings for window tiling because your mouse pointer could be
on a different monitor that has horizontal orientation.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3199>
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>
With window_is_terminal gone, "strict" and "smart" focus mode have no
behavioural difference. Let's broaden the scope of strict focus mode,
such that windows never automatically focus unless they are an ancestor
to the transient.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3063>
As noted in the comments of window_is_terminal, this is a hack. This
code has not been touched for the better part of a decade. App res_class
tends to differ between Wayland and X11, so it is likely that none of
these apps have been recognised as terminals under Wayland ever. Also,
there are reports that strict focus mode also does not work under X11,
likely due to changes in these terminal apps over the years resulting
in different res_class than those manually specified in here. Let's remove
this hack and change strict focus mode accordingly.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3063>
Current behavior pushes a window which receives focus to the start of
the MRU list on every workspace it is on. By focusing a sticky window
the default focus on all other workspaces changes as well. This is fine
for sticky windows explicitly marked as sticky by the user but if a
window is on a secondary output and workspaces are only on the primary
output the behavior is unexpected. Instead we want the window to be the
default focus only on the current workspace but also keep those windows
in a relative MRU order to each other on all workspaces.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2681
Fixes: 058981dc1 ("workspace: Focus the default window only if no window is focused")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2909>
We are attempting to show windows that do not yet have a
surface/buffer, this makes GNOME Shell avoid transitions
for these windows.
Since on Wayland X11 windows are also Wayland surfaces,
this check is also valid for these, and is thus made more
generic to also cater for these windows.
Eventually, meta_window_update_visibility() is called
when the surface gets its buffer, so the window can be
neatly animated.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2611
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2975>
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>
Normally, mutter implicitly allows a window being shown to take
focus. This is normally desired, except it steals input from
GNOME Shell self. Avoid focusing the just shown window in those
situations.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2878>
Ensure we preserve the fast zero-copy paths in Xwayland fullscreen
windows, instead of maybe rendering the client surface on top of the
frame surface, and providing the latter to the compositor.
To achieve this, additionally synchronize frame state when
recalculating features (e.g. after fullscreen/unfullscreen), and
account for this new condition when creating or destroying frames.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2797>
This looks like a bug: There's no reason why windows which advertise
min-size hints that are exactly the size of the workarea should not be
allowed to maximize, so change the checks here to allow for that.
The commit message of 7f64d6b9 also makes the point that this was not
intended, as it says "larger than".
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2873>
After !2489, the active workspace's MRU list is now used to pick
the next focus window instead of the stack order.
This list is currently only updated on focus, which can lead to
surprising behavior when closing a window after activating its
ShellApp in the shell.
That is because raising a window (as part of shell_app_activate())
will only change the stacking order, so when closing the active
app window, the focus will switch to whatever had focus before the
app was activated, not the app's next window.
In order to allow gnome-shell to address this, add a new
raise_and_make_recent() method that also adjust the MRU order.
https://gitlab.gnome.org/GNOME/mutter/-/issues/2540
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2866>
When modal dialogs are attached, and we set the parent/transient-for
after setting the modal type, the attachedness isn't updated. This is
(apparently) not the case for X11 windows, as they go through a
unmanage/manage dance avoiding the issue.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2810>
