Returning a GLib.Error from a method invocation will encode the
error when sent over the wire. In case the error itself is already
an encoded remote error, just passing it on will result in double
wrapping.
Avoid that by stripping any remote error information before
returning it.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3159>
(cherry picked from commit a5d33026f0)
Pipelines for non-protected branches are set to 'manual', and
thus cheap. However they may still get picked by `@marge-bot`,
meaning that the bot waits for the completion of a pipeline that
never starts.
Avoid that by not creating pipelines for branches with open
merge requests.
Credit to Jordan, who came up with this for gst.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3153>
(cherry picked from commit d3e96a36ce)
If something grabs the key focus while a modal is pushed, keeping
key-focus on that actor seems like the smarter thing to do than setting
it back to the last focus after the modal gets popped again. So check if
the key focus actor that we set when pushing the modal got changed when
popping that modal, and if it got changed, simply don't touch key focus.
This fixes a bug with the close dialog, where key focus isn't correctly
set to the dialog after alt-tabbing to a window showing a close dialog.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/786>
(cherry picked from commit 4d544d7b56)
When setting the key focus to `this._dialog`, the default button is not
automatically focused and no button has key focus.
Use the `initialKeyFocus` property of the dialog instead, and set focus
to the default button if the dialog is not already focused.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/786>
(cherry picked from commit de834fe307)
Now that StIcon updates its texture automatically on icon theme
changes, we only have to recreate icon actors that aren't StIcons.
(This probably only applies to the folder icon in the app grid
where the sub-icons do use St.Icon, but making that assumption
feels dodgy with an API as generic as `createIcon()`)
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3141>
(cherry picked from commit 8a1f44f10a)
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)
The values of the two control widgets are syncronized, meaning
that both emit signals when the local value changes, regardless
which one is visible and is actually used by the user.
This is not ideal because it leads to two dbus calls
per local change. To alleviate this, only consider
changes from the widget that is visible.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3086>
(cherry picked from commit c227d0b38e)
The logic could enter an infinite loop because it tried to
propagate local changes to g-s-d that were caused by signals sent
by g-s-d. For example:
1. slider is set to 50
2. Set(50) dbus call is sent
3. slider is set to 51
4. Set(51) dbus call is sent
5. PropertiesChanged arrives due to Set(50)
6. this._sliderItem.value is set to 50
7. notify::value is emitted from this._sliderItem
8. Set(50) dbus call is sent
9. PropertiesChanged arrives due to Set(51)
10. this._sliderItem.value is set to 51
11. notify::value is emitted from this._sliderItem
12. Set(51) dbus call is sent
To alleviate this issue, block signal handlers when the local state is
changed due to a remote event.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7111
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3086>
(cherry picked from commit be944ff2dc)
Our telepathy component has been optional for years, and it is
disabled by default on major distros, so we cannot assume that
it handles any particular notifications.
Plus Empathy itself is mostly dead, so it's unlikely to be used
much anymore anyway.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3110>
(cherry picked from commit 3f4f74689e)
Instead of manually formatting the error message and stack, use the same
formatting mechanism as we do when displaying errors to the user that
occur while opening extension preferences. This should correctly
indicate where syntax errors from imported modules occur.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3041>
(cherry picked from commit 1692004b6b)
Previously, when we formatted SyntaxErrors with toString(), they
wouldn't display the file/line/column where the syntax error occurred.
This adds a utility function that performs a more comprehensive
formatting that displays location information for SyntaxErrors, as well
as the .cause property of the error if it is present. This formatting is
equivalent to what we do in gjs-console when logging an error.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3041>
(cherry picked from commit a1a320d3d1)
Ideally we would replace the sliced-image based animation with a
themed `process-working-symbolic` icon and rotate it, so the spinner
simply picks up the current foreground color.
Unfortunately the `repeat-count` property does not work for rotations,
so to fix the broken spinner in the light variant
in the meantime, include assets for both variants and swap them
out at runtime.
Not everything in the light variant is actually light (overview,
OSDs, ...), so use a simple heuristic on the text color to decide
which asset to use.
Close https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6783
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3080>
(cherry picked from commit 1dda339395)
The properties passed to the constructor are currently used
directly in anonymous functions. Store them in properties
instead, so they become accessible outside the constructor,
including for changing them.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3080>
(cherry picked from commit 74445249db)
logError() prints an exception with an optional prefix, and is
used fairly commonly through-out the code base.
The problem is that by being defined in gjs, it uses "Gjs" as the
GLib log domain, not our own as expected.
Address this by adding a small override that implements the function
with console.error().
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3072>
(cherry picked from commit dc655b9ed0)
If an interface has any signals, we don't want to auto-shutdown
while a caller is still connected to a signal.
Unfortunately we can't tell whether there are any signal connections,
so we track all callers instead, and keep the service alive while
any of them is still on the bus.
For services that we call from gnome-shell itself - like screencasts
or extensions - this has the unintended side effect of effectively
disabling auto-shutdown.
Address this by exempting the org.gnome.Shell name from sender
tracking.
Services that we expect to keep running for the lifetime of the
shell already disable auto-shutdown, so the only downside is a
small startup delay to resolve the well-known shell name.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7250
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3052>
(cherry picked from commit ebe1a4d303)
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)
In the absence of a fade-out it doesn't make sense to clip them sooner
than that.
So now we make the left and right padding equal to the border
("box-shadow") width and leave the top/bottom padding unchanged.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3031>
(cherry picked from commit 98654e5446)
Now that both the website and the Extension app support the custom
"version-name" field, we should expose it in the CLI tool as well.
As a more developer-oriented tool, keep showing the automatic
version along-side the new field when both are set.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3034>
(cherry picked from commit ca47e7f8e3)
The extensions site recently added support for a custom
"version-name" string in metadata:
gitlab.gnome.org/Infrastructure/extensions-web/-/merge_requests/154
This allows developers to control the version that is exposed to
users. As the version according to the developer is almost always
more relevant than the automatic version assigned by the website,
use it instead of the "version" field if set.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2995>
(cherry picked from commit 6db55eaea6)
