St.Icon is very commonly used for displaying themed icons, yet so
far updating the icon on icon theme changes is left to the caller.
Unsurprisingly, very few actually do that, with the result that
for most icons, icon theme changes only take effect after a delay
(say, a color change on hover) or not at all.
This is also inconsistent with GTK, where Gtk.Image will automatically
pick up icon theme changes.
Address this by tracking whether the current icon corresponds to
a themed icon, and update it automatically on theme changes if
it does.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3141>
(cherry picked from commit 671c242958)
strstr() in find_class_name() will always consider "" a match so the
loop was not stopping at the end of the class_list. None of the matches
within the class_list would satisfy the return conditions, unless the
class_list was either an empty string as well or has a trailing space.
So this ends up with a match outside of the allocated string that
happens to satisfy these conditions by chance which then leads to the
class string containing some of this unrelated memory. Or it might lead
to a segfault.
This adds checks to the public API that uses find_class_name() to
prevent extensions from accidentally triggering a crash this way or
having some otherwise unexpected results.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7152
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3006>
(cherry picked from commit dc931e82cd)
The docs say that `st_adjustment_set_values()` emits the `changed`
signal only once but it's actually emitted for each changed property,
this uses the `dispatch_properties_changed` vfunc to emit the `changed`
signal only per call to `st_adjustment_set_values()`. As a positive
side effect this also makes it possible to use `g_object_freeze/thaw_notify`
to compress the `changed` signal emission when using the setters for
properties.
This also fixes the wrong emission of the `changed` signal in
`st_adjustment_set_values()` when only the `value` property is changed.
Side note: the code is heavily inspired by GtkAdjustment
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3023>
(cherry picked from commit 78eb5f2a68)
We hide scrollbars with POLICY_AUTOMATIC when the content of the scroll
view fits completely inside the view without having to scroll. In this case
it seems like a good idea to give the content the full available size
without subtracting scroll bars from that size.
So subtract the scroll bar from the size we give to the child only when
the scroll bar is actually visible, when it's invisible subtract 0 instead.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2190>
(cherry picked from commit 65e56183b1)
StScrollView applies the policy of whether to show or hide the scroll
bar,
and with the AUTOMATIC policy the scroll bar should be hidden as soon as
the
content of the scroll view is small enough to fit without scrolling.
Now we only know about the final size of the content when we're inside
st_scroll_view_allocate(), so that's where we can decide whether the
scroll
bar should be visible or not. Clutter really doesn't like calling
clutter_actor_show/hide() in the middle of an allocation cycle though,
so
what we do instead is saving the state into priv->vscrollbar_visible,
and
then just not painting the scroll bar based on that in a paint() vfunc
override.
This approach is not great for several reasons, it means we also have to
override pick() and finally it means the paint volume of the scroll bar
is
incorrect.
While the greatest solution to this would be to just hide/show the
scroll
bar inside the allocate() function as it is possible in gtk, we have an
established pattern for this kind of case too: We usually allocate a
0-sized
rect for the thing we want to hide, so let's do that instead.
A nice side effect is that we can conveniently drop another paint() and
pick() vfunc override.
Part-of:
<https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2190>
(cherry picked from commit a59a992daa)
As per the warning emitted when destroying without closing first
GdkPixbufLoader finalized without calling gdk_pixbuf_loader_close() - this is not allowed.
You must explicitly end the data stream to the loader before dropping the last reference.
closing it is necessary.
Create the GdkPixbufLoader after loading the file contents so that
the loader is guaranteed to be closed before it is destroyed.
(`gdk_pixbuf_loader_write()` closes it on failure.)
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3008>
(cherry picked from commit 3e7027821d)
This reverts commit 575ba13b9b.
That commit did not actually prevent the "Unknown" application from
showing up in the dash or app switcher when the recorder was running,
but it introduced a problem with Proton which also uses gstreamer OpenGL
elements in its transcoder. This was causing the overview to get stuck
while the transcoder was running due to the app for the
"OpenGL Renderer" window being null.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7042
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3000>
(cherry picked from commit bf742c3926)
meta_window_raise_and_make_recent() now only works as advertised
for windows on the active workspace.
That results in the following unexpected behavior:
1. open two windows of an app (say: terminal)
2. open another app, maximize the window for best effect
3. switch to another workspace
4. super+tab to the first app: both windows are raised
5. close the window; instead of moving focus to the
2nd app window, both windows disappear because focus
is moved to the app from 2
This was fixed with new mutter API on the main branch, but
for the stable branch it is easier to work around the issue.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2959>
Storing the pointer to the fade effect only works as long as we control
all the code that can modify the effects of an actor, but this is not
the case in the presence of extensions. Apparently some extension
manages to remove the effect, which leads to fade_effect pointing to
some invalid address by the time dispose is called, leading to a crash.
This instead uses clutter_actor_get_effect() to get the effect when it
is needed to avoid crashing in these situations.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6521
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2974>
The pipeline contains a GST plugin that pops up an unclosable
zero-sized window.
Unfortunately we did not manage to come up with a proper fix
in time, so for now explicitly exclude it from app tracking.
This does not address all issues (it still prevents the
window's workspace from getting removed, even when it appears
empty), but at least it avoids the most confusing effect by
preventing the "app" from showing up in dash, alt-tab etc.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6763
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2956>
Nowadays, Clutter knows what an implicit grab is, which gives
us already the feel that we are after with buttons (e.g. press
and drag on the button will not enter other actors meanwhile).
ClutterGrab was only added to provide that feel meanwhile, and
it's also slightly more intense (e.g. altering keyboard focus,
or triggering leave events on all parents of the button) which
may trigger side effects.
An example is the IBus candidates popup, where the pagination
buttons may indirectly trigger dismissing of the entire popup
when interacted, by stealing the keyboard focus to the
client/actor doing IM.
Related: https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2497
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2244
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2924>
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>
