Since we now remove all theme nodes on a stylesheet change (ie.
StTheme's "custom-stylesheets-changed" signal) instead of only
invalidating them, those nodes may not be accessed anymore as soon as
"custom-stylesheets-changed" is emitted.
It turned out though that when comparing them to the newly generated
nodes in `st_widget_recompute_style()` using the
`st_theme_node_paint/geometry_equal()` functions, the properties of the
old nodes will still be accessed, causing a crash since the
CRDeclarations are already freed.
To fix that, keep the reference to the CRStylesheet, which owns the
CRDeclarations used by the theme nodes, around a bit longer, so it's
still possible to access the CRDeclarations inside the
"custom-stylesheets-changed" signal handler. This allows us to compare
the old theme nodes to the new ones since the CSS properties of both are
still valid.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2709
StThemeNodes are built around the assumption that they're "immutable",
that means they are created once with certain parameters (that resolve
to certain css properties) and then replaced with new ones in case those
parameters changed.
Changes to the internal information stored by theme nodes (i.e. the css
properties, font names or the cached scale-factor) are not all handled
the same though: For changes to the font or the scale-factor we remove
all theme nodes from the cache and let the widgets which are on stage
generate new theme nodes. For changes to the css properties/the
stylesheet, we invalidate the properties of all theme nodes but keep
them in the cache using `_st_theme_node_reset_for_stylesheet_change()`.
So be a bit more consistent and handle changes to the css-properties/the
stylesheet stored by StThemeNodes the same way as changes to the font or
scale-factor.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1218
Theme node invalidation stops at unmapped widgets, and widgets
that forget to chain up to the default ::style-changed implementation.
This may leave stale nodes that were invalidated on
StThemeContext::changed, but are still set on widgets, and maybe
used for CSS property lookups.
Make sure that theme node invalidation happens always by moving
propagation outside the vfunc, and ensure the theme nodes are reset
across the full actor tree. Emission of ::style-changed, and obtaining
a new theme node may be delayed till when the actor is mapped.
The theme node is also cleared after unparenting an actor to avoid
stale references.
This ensures that all widgets get their theme node cleared after
stylesheet changes, instead of maybe being left with a theme node
that's been cleared of all its properties.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2541https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1223
Commit d76162c1c0 removed the ability to pass an extension UUID to
the Extensions app, when we moved the dialog to a portal and made
gnome-shell use it instead of spawning the extensions app.
However that missed that many extensions called out to the app to
open their own prefs.
While extensions are encouraged to switch to the new openPrefs()
convenience method added in commit 8030d9ad32, restore the old
behavior with a small script under the old gnome-shell-extension-prefs
name that either calls out to the portal or launches the app.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1220
I noticed the following warning while building the .deb package for
gnome-shell on Endless OS:
../src/st/test-theme.c: In function ‘main’:
../src/st/test-theme.c:549:3: warning: ignoring return value of ‘chdir’, declared with attribute warn_unused_result [-Wunused-result]
chdir (cwd);
^~~~~~~~~~~
(Of course this is very unlikely to fail in practice.)
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1208
We currently always ignore the minimum width of the hint actor and
request/allocate the preferred width. This can be problematic with
labels with long text, where we should rather ellipsize the text
than allow the entry to grow indefinively.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2607
When building the list of window PIDs, it's possible Mutter doesn't know
about the PID the client has and meta_window_get_pid() will return 0. We
should handle this case by not adding the PID to the list of PIDs
instead of adding an invalid one to it.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1184
MetaWindows get_pid() API changed to use the client PID, which also
works for Wayland clients instead of only X11 clients now. This API
returns 0 instead of -1 for invalid PIDs, so update our check according
to that.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1184
Each node stores the scale factor in place when it was created.
Creating nodes with the same style, but with different scale
factors, yields different nodes.
Use the node's scale factor instead of retrieving the context's
one.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1176
Since commit 6a42d77261 we invalidate the
cached properties for each theme node on stylesheet changes by iterating
over the hashtable of the theme context instead of listening to the
signal in each individual theme node.
That commit forgot one particular node though that's not stored in the
hashtable, but using the `priv->root_node` property instead: The theme
node that belongs to the stage.
So make sure we also invalidate the cached properties of the stage theme
node on stylesheet changes. This fixes various crashes that happened
with extensions providing custom stylesheets (emitting the
"custom-stylesheets-changed" signal on every extension enable/disable),
trying to access an already freed CSS property of the stage.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2584
Just like StIcon does, we should use a container widget for the fallback
app icon that we get using the cairo surface property. It's needed
because the widget returned by shell_app_create_icon_texture() can be
resized freely, while we want the aspect ratio of the actual texture to
remain the same.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2578
Commit 7ff7fb5d3b forgot to clear the
`priv->icon_texture` actor when returning from st_icon_update(), which
means we don't always switch to an empty icon if both gicon properties
are set to NULL.
Fix this and destroy the actor before returning early from
st_icon_update().
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1178
Commit c89d6a633 introduced a default fallback icon that would be displayed in
case the main gicon or the fallback gicon wasn't set or failed to load.
This broke the use case where a StIcon is created but no main icon or
fallback icon are set on purpose, for example the appindicator extension
which always creates a StIcon to represent icons in menu items but the
actual icons are only set if the application provides one, leaving the
menu showing the default fallback ("image-missing") icon for all menu
entries that don't actually have an icon provided by the application.
Fix that by only using the default fallback icon if the provided one
failed to load.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1173
The app-cache code currently stores the folder translations in a hash
that can be accessed via shell_util_get_translated_folder_name().
This hash uses the filename (inc. extension) for the "desktop-directory"
as key which causes an issue when trying to find the translation
on AppDisplay._findBestFolderName() which gets categories (folder names)
from the app info which doesn't contain the ".directory" extension.
Fix that by storing the filename without extension as the hash key for
the cached folder translations.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1168
It seems reasonable that an entry shouldn't allow entering text when not
reactive. The same could be achieved by changing the text's :editable
property, however that will disable scrolling if the text doesn't fit,
which may result in an unwanted size change.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2423
The text is part of the entry, so it is surprising that it can
still be edited when the entry itself isn't reactive. Address
this by setting up a binding instead of expecting all consumers
to handle the case themselves.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2423
This is documented as a value between 1 and 65536. However we were passing
a 0 value for 100% transparent colors, which is interpreted as "system
inherited" in pango_renderer_get_alpha() docs.
Ensure we respect this range by specifying the minimum allowed alpha (1)
if the color is fully transparent. If someone notices this 1/65535th change
I'll ask him how many pleiades can he count.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2504
(yes, again).
We want to completely clear the background framebuffer when switching
back to ACTOR mode to make sure the `background_fb.framebuffer` check
will fail in `update_background_fbo` when switching to BACKGROUND mode
again. Otherwise the checks in `update_background_fbo` will return TRUE
and we will keep using the background framebuffer that was created
before switchig to ACTOR mode.
While at it, also clear the background framebuffer completely when
changing the actor to avoid the same issue here.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1000
When blurring only the actor (ACTOR mode), we don't want to apply any
scale, it looks fine without using the resource scale and it also seems
like `clutter_actor_continue_paint` in `paint_actor_offscreen` only
draws an unscaled texture anyway (ie. if the resource scale is 2, only a
quarter of the framebuffer is being drawn to).
In BACKGROUND mode though, we need to scale the framebuffer using the
scale factor of the stage view (ie. the final scale factor for the
monitor) because the content of the framebuffer we blit is scaled using
that factor. Also, since the framebuffer we blit belongs to a stage view
and only includes the contents of this view, we need to adjust the
stage-coordinates of the actor to be relative to the stage-view.
To make sure we don't have to get the transformed actor size or position
multiple times during one paint-run and don't have to carefully floor()
or ceil() widths and positions, store the size of the actor (which is
also the size of the framebuffer) and its position relative to the stage
view inside a ClutterActorBox.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1000
A ClutterEffect is being painted as part of the paint cycle of
ClutterActor, where _clutter_effect_paint() is called before painting
the actual actor. With that, it's impossible that an effect gets painted
while it's disabled, so remove the check whether the ClutterActorMeta is
enabled before painting.
Also if everything works fine in Clutter, the ClutterActorMeta should
have an actor set and we've been notified about that actor in
shell_blur_effect_set_actor(), so assert that our cached actor is set
when painting the effect.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1000
The idea behind commit 3dd8ffc2bb to try harder to avoid empty
icon actors because of missing icons was sound, so implement that
behavior in StIcon itself:
If the main gicon was not found, and the fallback gicon isn't set or
wasn't found either, fall back to the standard 'missing-image' icon.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1127
The commit broke StIcon's :fallback-gicon property, as it relies on failure to load
an icon to determine that the fallback should be shown.
Luckily StIcon is the only user of st_texture_cache_load_gicon() (at least in
regular shell code), so we'll be able to implement the 'image-missing' fallback
there.
This reverts commit 3dd8ffc2bb.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1127
Add a small helper method to asynchronously "touch" a file and return
whether the file was created or not.
As g_file_make_directory_with_parents() doesn't have an async variant,
we need a C helper to make the entire operation non-blocking.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2432
Rely on the Pango renderer handling this properly, instead of tinting
the full ClutterText in the color specified through css.
Also set the caret color explicitly, since it used to be set as a side
effect of clutter_text_set_color(), but no longer is.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/850
Commit da537cda43 moved the Shell.Screenshot API to GIO's async pattern,
but we never set the GError passed to the *_finish() functions and only
indicate failure by returning FALSE.
The expected behavior is to throw an error in that situation, so make sure
we do that.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1123
If a given icon is not available for neither the current theme nor any
of the fallback options (default theme -"Adwaita", "gnome"...), the
call to gtk_icon_theme_lookup_by_gicon() will return a NULL value, which
returned by the Shell Toolkit as is, causing trouble in the Shell's JS
code when calling shell_app_create_icon_texture() to create an icon.
To at least mitigate the chances of this having this issue happening, we
should at least try to load the standad 'image-missing' icon from the
Icon Naming Specification spec when we receive a NULL here, so that
at least we try to show something to the user, even if it's ugly.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1121
We want to make the extensions app code more self-contained to make it
easier to build separately, and ultimately make it available on flathub.
One complication we are facing is that it is currently all over the source
tree:
- js/extensionPrefs for the main code
- src for the launcher process
- data for .desktop file and icons
Switching from a C launcher to the imports.package module allows us to
consolidate the first two, and will also take care of the annoying
setup bits (defining JS search path, extending GI lookup, loading
resources).
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1081
While we can use the libnm API directly from JS, the call will
synchronously load the VPN service descriptions from disk.
Previously we were lowering the impact by caching the result,
but as we stopped doing that, it becomes more important to address
the issue properly and move it off to a thread.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2386
For sandboxed apps, permission to talk to org.freedesktop.Notifications
looks innocent enough. However as all exported services share the same
connection to the session bus, that permission actually grants an app
access to *any* shell D-Bus API.
While we want apps to use the notification portal, it is still common
for apps to use libnotify, raw D-Bus calls or even notify-send.
We don't want to give those apps a way to circumvent most of the sandbox
restrictions, so stop owning the org.freedesktop.Notifications name.
In a next step we will implement a separate notification-daemon that
exposes the API on the well-known address and proxies any requests to
the real implementation in gnome-shell.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/547
This caches GAppInfo so that the compositor thread does not have to perform
costly disk access to load them. Instead, they are loaded from a worker
thread and the ShellAppCache notifies of changes.
To simplify maintenance, ShellAppCache manages this directly and the
existing ShellAppSystem wraps the cache. We may want to graft these
together in the future, but now it provides the easiest way to backport
changes to older Shell releases.
Another source of compositor thread disk access was in determining the
name for an application directory. Translations are provided via GKeyFile
installed in "desktop-directories". Each time we would build the name
for a label (or update it) we would have to load all of these files.
Instead, the ShellAppCache caches that information and updates the cache
in bulk when those change. We can reduce this in the future to do less
work, but chances are these will come together anyway so that is probably
worth fixing if we ever come across it.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2282
