The timeout seems to have been carried over from the old code that
relied on gnome-shell calling 'GetEvents' after every 'Changed' signal
where it was used to throttle the signal. In the new code where
calendar-server is sending the changes themselves via signals this is no
longer necessary and actually causes a delay when switching between
months.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2992
When using the NVIDIA driver, textures tend to loose their pixels when
suspending. In the past we handled this by figuring out when the NVIDIA
driver was used, and reload the background whenever we noticed we
resumed from suspend.
This shouldn't be needed anymore after
https://gitlab.gnome.org/GNOME/mutter/merge_requests/600, as it should
handle this by listening to video-memory-purged signal. Thus remove our
special handling here.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1358
Since commit b60836932 we only allow WM_CLASS matches for sandboxed
applications if the found app's ID is prefixed by the sandbox ID.
The existing check still has a hole in it though: "org.example.Foo"
and "org.example.FooDevel" are different applications, yet the former
is a prefix of the latter.
So tighten the check by including a trailing "." in the checked prefix;
this excludes cases like the above, while still working for the regular
case of a single .desktop file because our app IDs include the ".desktop"
suffix.
Spotted by wjt.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1357
Currently our heuristics for matching a window to its app check
for the application ID before the WM_CLASS, as the ID is more
reliable in so far that it is outside the application's control
and so it cannot use it to spoof a different application.
However this also prevents applications with multiple .desktop
files like LibreOffice from matching any .desktop files other
than the one under the main ID.
Since we now no longer allow the WM_CLASS to match a .desktop
file that doesn't belong to the sandboxed application, we can
fix that issue by checking the WM_CLASS first, without opening
the door to spoofing.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/219
At least flatpak (no idea about snap, sorry) enforces that all .desktop
files exported by a sandboxed app use the application ID as prefix.
Add the same check when trying to find a match based on the WM_CLASS,
to prevent sandboxed apps from matching a .desktop file they do not
own.
At the moment this is unlikely as we check for a match on the
sandboxed app ID first, but we are about to change that.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/219
Now that we can always associate a GIcon with the app, add a method
to access it. While create_icon_texture() is still likely to be more
convenient in most cases, exposing the icon can still be useful, for
example to add it to a different kind of actor or to compare it with
other GIcons.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1342
We still load the surface into an StImageContent, but instead of
adding the content to an actor we hand out, return the content
itself (as GIcon).
That means we lose the ability to specify an icon size, but as we
get the pixel data from a fixed-size surface anyway, that shouldn't
matter much in practice.
Not to mention that the function is only used for fallback X11 icons,
which are already shit more often than not.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1342
On the one hand, this is a bit of a stretch: StImageContent is what
we create from GIcons.
But on the other hand, there's some justification: StImageContent does
represent an image (and likely icon) after all, and there's some
precedent with GdkPixbuf.
In the end as we don't care about serialization or loading from other
API, we can go with a very crude implementation that allows us to
pass out a content as GIcon and use it directly when "loading" it.
We will use that soon to represent X11 window icons as GIcons, which
in turn will allow us to unify app icon handling.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1342
ClutterActor provides the same function, but with a different return
value. So since we already switched to the ClutterActor implementation
in our C code, we can now safely remove st_widget_get_resource_scale()
and update the JS code that's still using the old API.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1287
Instead of using the "notify::resource-scale" signal and StWidgets
"resource-scale-changed" signal, use the new "resource-scale-changed"
signal of ClutterActor, which replaces its "resource-scale" property.
Since we'd now have two "resource-scale-changed" signals, one on
ClutterActor and one on StWidget, remove the StWidget one in favour of
the new one.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1287
When scrolled, the container's allocation is smaller than the allocation
of the content. To account for that, commit 2717ca9d08 added the
additional size reported by the layout manager to the content allocation.
However as it did so unconditionally, we now allow children to extend
outside the parent even when *not* scrolled, which breaks any constraints
set on the container (like "width" or "max-height").
Fix this by only extending the child allocation in scrollable dimensions.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2491
The performance of the icon grid was being hindered by a large number
of primitives (a few hundred) being copied from the CPU to the GPU on
each frame. This was first noticed in mutter#971 but we failed to
investigate all the issues at the time.
You can also see the high number using `COGL_DEBUG=batching` or
`COGL_DEBUG=disable-texturing`. So now it's obvious that high number is
every letter of every label being uploaded as a separate quad. Let's not
do that and instead treat the whole label as a single quad/texture.
Measured performance on an i7-7700 at UHD 3840x2160:
Journal entries per frame on the icon grid:
* Before: 288 (18 KB copied from CPU to GPU)
* After: 73 ( 4 KB copied from CPU to GPU)
Spring animation:
* Before: 20-30 FPS, avg 22/peak 45 milliseconds per frame
* After: 30-40 FPS, avg 14/peak 28 milliseconds per frame
Scrolling the icon grid:
* Before: 15 FPS, 50 milliseconds per frame
* After: 30 FPS, 28 milliseconds per frame
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1329
As the view now scrolls from right-to-left in RTL locales, the
scroll bar handle should reflect that.
Likewise the event handling needs adjusting as well: Scrolling
left should increase the adjustment value, and clicking the
trough to the left of the handle as well.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1318
clutter_text_get_selection() creates a copy of the selected text which
gets passed to st_clipboard_set_text() which creates its own copy. The
copy returned by clutter_text_get_selection() however never got free'd.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1306
The HasCalendar property reflects whether there are any views, and views
change either when clients appear/disappear or when the time range changes.
However we currently only emit the PropertiesChanged signal for the former,
fix that.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1300
The shell mime sniffer goes through all the files in a directory,
however in case a file content type is not recognized, the GIO function
g_file_info_get_content_type() may return NULL, causing a crash when
looking up into the content type tables, as they are supposed to contain
strings only and they use `g_str_hash` has func, which doesn't support
NULL values.
So, in case we get an invalid content type, let's just ignore it,
without adding it to the cache as we do in the nautilus code that was
inspiring the sniffer.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2643
As outlined in commit 36b8dcbe07, we can end up with wrong icons
if the icon theme changes right after a GTK theme change to/from
HighContrast triggered a theme reload.
That's because when we reload icons for the new icon theme, there
are already pending requests due to the icon-style change; those
requests are simply re-used for the new icons, with the existing
icon infos from the old theme.
The above commit applied a simple work-around by changing the
icon theme before the GTK theme, but that only works for the
HighContrast switch in our own UI.
It turns out that Settings also uses the "wrong" order, so the
issue still reproduces with the Universal Access panel.
So instead of relying on everything changing the settings in the
order we expect, cancel all ongoing requests on icon-theme changes.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1277
Since the `MetaSelection` of the global `StClipboard` is private (and
should be), there is no reasonable way for extensions or external code
to query the supported mime-types.
Add `st_clipboard_get_mimetypes()` so this can be queried without
poking around in private code.
closes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2819
Since e06109c23c we keep old theme nodes
valid during the emission of the "custom-stylesheets-changed" signal.
It turns out that we might still look up the file of a stylesheet using
the files_by_stylesheet hashtable during the emission of that signal,
causing a crash because the assertion in _st_theme_resolve_url() fails.
So fix that and remove the stylesheet entry from the files_by_stylesheet
hashtable after emitting the "custom-stylesheets-changed" signal. And to
be consistent, also remove the entry from the stylesheets_by_file
hashtable after emitting the signal.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2757
`StBoxLayout` has a couple properties (`vertical` and `pack-start`)
improperly referenced as signals, and is somewhat unclear these
properties are wrappers around the underlying `ClutterBoxLayout`
properties.
Fix these up and add references to the underlying properties, rather
than redescribing them.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2816
Avoid starting/stopping the gsd-xsettings systemd unit if the shell itself
was not started via systemd. In the lack of a user session manager, we
have no means to neatly start/stop services, so should rely on the good
ol' gnome-session to do this for us.
This changes the return value meaning slightly, TRUE means "service did
start", FALSE otherwise. The error is only raised if we ought to start,
but it produced an error somehow.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1238https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2755
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
