Unit tests currently load shell sources directly from the
filesystem.
This is currently blocking generated sources - namely config.js - to
ESM, because a relative import from the source dir will fail to
locate the file in the build dir.
Address this by using the same GResource as gnome-shell instead of
direct filesystem access, as the resource will always include all
sources files at the expected location.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2880>
Glibc defines `d_ptr`/`d_val` to be a relocated address on most
architectures, except for riscv and mips where it is just an offset from
the binary load address. So we need to convert `strtab` from an offset
into a pointer for riscv and mips.
Internally within glibc there is the `D_PTR` macro for doing this, which
relies on private data hidden in an ABI-unstable part of `link_map`. So
we can't use the same conditional logic as glibc does internally.
Our solution is to detect when `strtab` is unreasonably low (below the
address of our binary) and so it must be an unrelocated offset. In that
case we just do the relocation manually.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6528
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2718>
We currently consider idle nodes as in use to avoid too fast state
changes and thus flickering of the indicator icon. However, the current
idle timeout is rather long and arguably confusing for users.
Thus switch to only consider running nodes as in use, but delay
disabling of the indicator by 500ms.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2854>
Pipewire allows us to easily track whether any cameras are in used by
checking the state of camera nodes. Add a simple camera monitor to the
shell, allowing us to show e.g. a status indicator.
Naturally the monitor is limited to apps using Pipewire for camera
access and thus subject to the same chicken-egg problem like the camera
portal - it could confuse users that apps may use the camera without
being noticed by the monitor. The hope and assumption here is that a
better shell integration might speed up adoption of the new camera APIs
Pipewire 0.3.49 is required for refcounted `pw_init()`/`pw_deinit()`.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2840>
GJS provides utilities to run scripts given a filename, using those
utilities we can remove most of the logic implementing file loading.
Additionally the REPL logic does not make much sense for a test
runner and is unused, so remove it.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2822>
GThemedIcon considers the "-symbolic" suffix when generating
fallback names (i.e. "foo-bar-symbolic", "foo-symbolic", "foo-bar",
"foo").
That means now that we prefer more accurate name matches from any
theme over fallback matches from higher-priority themes, we no
longer need to special-case symbolic names for preferring symbolic
matches over full-color fallbacks.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2824>
When resolving an icon name, we currently look in all themes in
order whether one of the requested names matches.
That means, a "keyboard" icon from the configured theme will
trump over any of "keyboard-shift", "keyboard-brightness" and
"keyboard-preferences" from lower-ranked themes (like "Adwaita"
and "hicolor").
That applies to custom icons we include in the resource, which
are added to the fallback ("hicolor") theme.
We are less bound by the named-icons spec than GTK, so we can
adapt the lookup to prefer the most accurate match to matches
from the highest priority theme.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2824>
The purpose of the tool has shifted from running a limited set
of performance tests repeatedly to collect performance data
and catch regressions, to a wrapper that drives gnome-shell via
scripts for tests.
With that, the concept of a "default" script doesn't really make
sense anymore.
Instead, turn the argument from an optional flag into a required
parameter. This will allow us to stop bundling the existing tests
in a follow-up commit.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2812>
The original purpose of the tool was to collect performance data
that would optionally be uploaded to a server in Owen's living
room. While the corresponding scripts are still included (although
the server was probably dismantled years ago), the tool is mainly
used for running gnome-shell with scripted tests nowadays.
Rename the tool to reflect that.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2812>
Environment variables aren't the best option to pass parameters
to a process (wouldn't it be "fun" if SHELL_PERF_MODULE appeared
in a regular user session?).
Instead, use a (hidden) --automation-script command line flag to
specify a script file that should be used to drive an automated
session.
As a side effect, the script no longer has to be relative to the
main module itself, so it will be possible to run scripts that
aren't bundled with the shell sources.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2812>
When using fractional scaling, the size of the loaded image with
applied scaling may still differ from the displayed size. This
is currently addressed by syncing the size of all slice actors
in the (probably only) caller.
Instead, set the actors to fill their parent automatically.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2798>
If gjs itself defines ARGV, it only holds the arguments that are
passed on to the script, and javascript code should combine the
programName and ARGV (or the newer programArgs) when it needs a
C-style argv array.
Do the same in the portal-helper process instead of passing along
the original C argv, to avoid confusion when accessing the arguments
from javascript.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2786>
gjs now has an internal mainloop that it can spin to resolve
module imports. That loop uses the thread default context,
so its possible that other sources, namely from mutter, get
dispatched when iterating the context. If that happens before
mutter is properly initialized, this will lead to a crash.
GjsContext needs to iterate its internal mainloop when initializing
to resolve internal modules, to avoid iterating Meta's mainloop and
triggering events before Meta is ready we will initialize the Shell
global and thus the GjsContext (js_context) before Meta.
Once GjsContext is initialized, we can call meta_context_setup().
Once Meta is setup and started, we'll run init.js which uses GJS'
internal promises API to set a "mainloop hook". The mainloop hook
is run immediately after the module returns so GJS will not attempt
to iterate the main loop again before exiting.
Also adjust the 'headlessStart' test to not wait for the
MetaContext::started signal, as that signal has now already
been emitted when the code is executed.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6691
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2781>
The windows we create use a simple pattern as content, as that's
easier to follow than completely empty windows. GTK4 no longer
allows hooking into the drawing of arbitrary widgets, so prepare
for that by using a dedicated subclass instead of a signal handler.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2733>
The callback would schedule a clutter_actor_destroy() on the first
argument. Unless told otherwise, this is the same actor that is
already being destroyed, so this is a no-op.
Instead, the intent is to make the clone follow up destruction of
the window actor so that it results in correct removal of this
window from the ShellWindowPreviewLayout. Use a swapped connection
to pass the clone actor as the first argument of the signal callback.
Fixes: 04c781674c ("Move WindowPreviewLayout from JS to C")
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6570
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2756>
If we have multiple desktop ID's that share the same startup-wm class
and none of them is actually matching the desktop-id, then we should
exclude the ones that should not be shown in the current desktop.
This will help preventing cases such as the previous one in case no
desktop file ID would match the startup-wm-class exactly.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2721>
When fetching the desktop ids into a map of startup-wm classes we meant
to give the ones that match the desktop ID more priority, however
this did not happen because we were always comparing a desktop
file id, including the `.desktop` suffix, with a wm-class that generally
does not include that.
This is the case of gnome-system-monitor, that provides two desktop
files, one of which is OnlyShowIn=KDE but both have the same
StartupWMClass and thus the first parsed is preferred, even though its
desktop-id is gnome-system-monitor-kde.
As per this, remove the .desktop suffix when comparing it with the
startup-wm-class, keeping the old check just in case.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2721>
This is a small one time leak if there is more than one entry in the
search path due to multiple iterations overwriting the old pointer
before finally going out of scope.
Fixes: 934faaace ("st/icon-theme: Start using g_autofree")
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2737>
When loading a symbolic SVG, the original file is wrapped in
a header that includes a generated stylesheet with the
appropriate colors, plus an overall opacity.
The opacity value is clamped to values between 0 and 1, which
directly matched the alpha field of the GdkRGBA type. However
since we moved to StIconColors/ClutterColor, the alpha field
is now in the range [0..255], any alpha value other than 0 now
results in full opacity.
To fix, translate the [0..255] integer into a [0..1] double
before using it as opacity.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2731>
