This allows neat tricks like first arranging the script `fakegdb`:
```sh
function ignore_gdb_arg() {
if [[ "$1" == "--quiet" ]] || [[ "$1" == "--args" ]]; then
return 1
else
return 0
fi
}
ignore_gdb_arg "$1" || shift
ignore_gdb_arg "$1" || shift
echo exec "$@"
```
then running
```sh
meson test -C build -v perf-basic --test-args '--wrap "gdb --args"' --gdb --gdb-path `which fakegdb`
```
To make it possible to run the perf test case with gdb running the
actual gnome-shell.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1349>
This test runs all of GNOME Shell using the headless backend inside a
mocked D-Bus environment. The basic test tests, well, basic things, like
the panel menu, the overview, showing the app grid view, as well as
going back to the session view.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1349>
If one wants to run tests the non-installed gnome-shell, that currently
fails as gnome-shell the executable attempts to link against
./build/src/libgnome-shell.so, but when GObject introspection tries to
find what library to link to for Shell, it goes to the installed
libgnome-shell.so, causing two different versions of libgnome-shell.so
to be loaded.
This, however, can be avoided thanks to meson adding $ORIGIN paths to
relevant libraries before installing an executable. What this means in
practice is that we can inspect ourself upon startup, discover whether
the RPATH/RUNPATH header contains $ORIGIN, and if so, expand it to the
directory containing the executable, and prepend the introspection
search paths with said directory.
This effectively means that the introspection machinery now finds the
same library that the linker linked the gnome-shell executable with,
making it run successfully.
It's not possible to use $GI_TYPELIB_PATH since
g_irepository_prepend_library_path() takes precedence. There is no
"append" variant of that API.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1349>
Tearing down gjs means that we won't have any dangling references kept
alive by GC or otherwise alive Javascript objects, when we finally tear
down the mutter context. This allows for a clean shutdown of GNOME
Shell.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1349>
Commit 9168f6055e marked the parameter as nullable, which is in
conflict with the precondition check. But given that NULL is
valid for the underlying ClutterText (and GtkLabel accepts it
as well), there's no strong argument for disallowing NULL, so
remove the precondition check.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2465>
Only when part of it is actually visible.
Because the central rectangle is generally the largest part, this
eliminates most of the shadow's render time. For example, animating
`.workspace-background` by tapping Super, the shell's overall render
time is reduced about 15%.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1915>
WorkspaceBackground's allocate is a hot function called every frame
during overview animations. Port it to C.
While we're at it, cache the work area and the monitor geometry, which
do not need to be re-fetched on every allocation.
This reduces the average WorkspaceBackground allocation time from
0.134 ms to 0.017 ms. With four workspaces, scrolling the overview sees
an average WorkspacesView allocation time improvement from
1.104 ms to 0.678 ms.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2394>
The iterator was pointing to NULL when going out of scope, leading to
autofree not clearing the list.
==300183== 32 bytes in 2 blocks are definitely lost in loss record 14,798 of 38,939
==300183== at 0x484586F: malloc (vg_replace_malloc.c:381)
==300183== by 0x4D7D980: g_malloc (gmem.c:127)
==300183== by 0x4D95AB3: g_slice_alloc (gslice.c:1074)
==300183== by 0x4D96D96: g_slist_prepend (gslist.c:282)
==300183== by 0x487854F: shell_app_get_windows (shell-app.c:794)
==300183== by 0x48791A1: shell_app_get_pids (shell-app.c:1201)
==300183== by 0x488B293: shell_window_tracker_get_app_from_pid (shell-window-tracker.c:702)
==300183== by 0x488B632: get_app_from_window_pid (shell-window-tracker.c:370)
==300183== by 0x488B632: get_app_for_window (shell-window-tracker.c:436)
==300183== by 0x488B632: track_window (shell-window-tracker.c:549)
==300183== by 0x4CDBB75: g_cclosure_marshal_VOID__OBJECTv (gmarshal.c:1910)
==300183== by 0x4CD8BE9: _g_closure_invoke_va (gclosure.c:893)
==300183== by 0x4CF2A28: g_signal_emit_valist (gsignal.c:3406)
==300183== by 0x4CF2C2C: g_signal_emit (gsignal.c:3553)
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2367>
Even though GNOME Shell is not explicitly using structured logging via
G_LOG_USE_STRUCTURED, GLib uses it as default since 2016 [1], and so
we're de facto using it.
As per this, if backtrace on warnings is enabled, it is ignored since the
log handler isn't used anymore, and no dump is printed.
Thus, replace the default log handlers with writer functions instead, honoring
backtrace-warnings debug string.
[1] https://gitlab.gnome.org/GNOME/glib/-/commit/fce7cfaf40b6e1e50c9140aa0397f5
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/697>
Applications launched using D-Bus activation will have a returned PID of
0, which systemd interprets as moving the requesting process to a new
scope, causing GNOME Shell to be moved to another scope. Fix this by not
creating a systemd scope when PID is 0.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2305>
GTK4 added a convenience property for icon-only buttons. While that
use case is not quite as common in the shell as in GTK apps, it still
seems common enough to mirror the GTK API.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2254>
We started tracking all windows to make sure the assumption that any
window can be match to an app holds. It is not expected however to
ever represent OR windows in the UI, so it seems better to exclude
them from get_windows() instead of expecting everyone to filter the
return value themselves.
(The returned list still includes "uninteresting" windows like attached
dialogs, which can be important for cases like the correct MRU order in
alt-tab)
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5233
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2252>
When neither the theme node itself nor any of its parents specifies
an explicit text direction, we default to aligning to the left.
That's a good default for LTR locales, but for RTL aligning to the
right is a better one.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2247>
As first mentioned in commit 672171093, the CSS spec defines shadow
colors independently from the colors casting the shadow. It's not
a physical light simulation so a shadow is allowed to be a different
color from texture casting it.
This means we only care about the shape of the source where alpha
values of zero are adjacent to alpha values of non-zero. And all such
non-zero pixels should be treated as fully opaque for the purpose of
shadow generation. While this would be wrong for a physical light
simulation it does allow us to cast shadows around semi-translucent
shapes and better support CSS.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4477
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1918>
ClutterEffects are responsible for queueing redraws when their
properties change (and StScrollViewFade is a good citizen already), also
Clutter itself should queue a redraw when adding/removing an effect.
Users of Clutter should never have to queue redraws themselves (unless
they're implementing a custom ClutterEffect or ClutterContent), so don't
queue a redraw here.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2189>
The fade effect can also be added to the scroll view programatically
instead of using CSS via the st_scroll_view_update_fade_effect() API.
We make use of this API in the appDisplay, but since commit ba547ec1d
the fade margins get overridden to 0.0 from the ::style-changed handler.
Fix this by only setting the fade margins when CSS actually defines a
custom vfade/hfade offset.
Related: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5079
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2189>
Since now the resource consumption of the "style-changed" signal
handlers should be significantly lower, we can start emitting the signal
in all cases again as it was originally intended. This fixes some small
visual issues, like the battery percentage in the panel only being shown
on hover or updating the size of StIcons on scale-factor changes.
This effectively reverts f74c07b9ac
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/1708
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2099>
