ClutterImage as is, is very basic and doesn't really serve any purposes
other than being inherited by StImageContent. As we cannot easily push
ImageContent to Mutter by merging it with ClutterImage because it will
bring more GdkPixbuf usages and also because Clutter doesn't really deal
with theming bits.
Instead, merge it with StImageContent and let GNOME Shell take over from
here.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3547>
It can be useful to know whether an icon displays a symbolic (rather
than just requesting it). Add a new :is-symbolic property for that
purpose, backed by private API on StImageContent that allows the
texture cache to shuffle that information through to the icon.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3296>
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>
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>
Avoid using it by... guess it... yes! Copying the function
into an utility. This helper function to convert between
pixel formats is quite self-contained and unrelated to the
rest of GTK, so may be copied in place.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2655>
- move all icons to the icons directory
- rename some icons to be more meaningful
- put all icons on a resource sheet
- update references to icon name changes
- deprecate icons for those in standard set
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2141>
Creating a content object from a cairo surface may fail, in which case
we return an empty content with a 0x0 preferred size.
However when we treat such a content object as GIcon, we happily load
it anyway. Don't do that, so consumers like StIcon can fall back properly
to an alternative.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1761>
While most GIcons passed to this function cause a StImageContent to be
created with the requested size, cairo surface based icons already are
passed as StImageContent with a preferred size corresponding to the
size of the surface they were created from. As a result icons of window
backed applications were never scaled up like the other icons. Fix this
by ignoring the content size for these case.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1751>
This is how the code works and how it is already used from the C side.
There would also be no point in keeping this transfer none, because
textures generated from this function will not be shared and are not
kept in the cache.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1718>
This reverts commit 87558efbf130ec64b445da808b2bc162aebf352d.
The commit did not fix the bug it was supposed to fix, it just
complicated the code. The hopefully correct fix is in the previous
commit.
The point of this commit was to ensure everything gets removed when
bind->source gets removed. This however was already the case since the
signal handler was already connected to bind->source and has a
destructor registered that takes care of everything. And since gobject
destroys its signal handlers before it clears the weak refs, this new
weak ref was effectively never being used.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1718>
If the icon surface of a window got updated and its type or format no
longer match what we expect, st_texture_cache_reset_texture() might
overwrite the existing image in the bind with a new image, while still
keeping the weak ref on the old image. Due to this the old image might
trigger a st_texture_cache_on_pixbuf_notify() after the bind has already
been freed by g_signal_handlers_destroy() in the bind source. While this
usually would remove the weak ref, the weak ref it tries to remove is
on the new image, not the old one. The call to
st_texture_cache_on_pixbuf_notify() then tries to read the already
free'd memory from the bind which causes the cast to G_OBJECT to fail,
resulting in the crash.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3785
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1718>
Much of St is undocumented, aside from input/output arguments. This is
no doubt because a lot of it parallels Gtk closely, but is worth
improving since many new programmers are not familiar with Gtk.
closes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2983
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
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
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 3dd8ffc2bb1cefd603bcadabd8886dda3192dbd5.
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1127
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
st_texture_cache_bind_weak_notify calls g_clear_signal_handler which
then calls st_texture_cache_free_bind. st_texture_cache_free_bind frees
the bind structure, so by the time g_clear_signal_handler tries to write
bind->notify_signal_id, bind has already been freed.
Fix this by using g_signal_handler_disconnect instead.
This partially reverts 135d178d08
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/2334
Some (newer?) GCC versions complain when a g_auto variable isn't
initialized when declared, even when the initialization is guaranteed
to happen before the variable is used or goes out of scope.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2298
The used_scales hash table uses g_double_hash and g_double_equal which
try to read a double from the passed pointers. The pointers however were
pointing to a float, leading to an invalid read.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/974
We're storing in the texture cache images and scaled images appending
the scaling factor to the key. When a file changes the cache key
corresponding to that file is removed, but not the keys for the scaled
ones so that images in the cache are never reloaded.
This patch removes all keys from the cache related to the file that
changes, including those with the scaling factor.
A new set (hash table) was added to keep track of scale used to be able
to remove all possible images in the cache.
When the KEY is removed from the cache, we can look now in the scale set
for and each scale we also remove the key "KEY1.000000", "KEY2.000000",
etc.
Assuming that the number of used scales is small (I would typically
expect one or two), the overhead should be negligible.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/567
Whenever an app is installed, the usual routine is
to run 'gtk-update-icon-cache' after installing all
of the app's files.
The side effect of that is that the .desktop file of
the application is installed before the icon theme
is updated. By the time GAppInfoMonitor emits the
'changed' signal, the icon theme is not yet updated,
leading to StIcon use the fallback icon.
Under some circumstances (e.g. on very slow spinning
disks) the app icon is never actually loaded, and we
see the fallback icon forever.
Monitor the icon theme for changes when an app is
installed. Try as many as 6 times before giving up
on detecting an icon theme update.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/661
The texture cache, right now, only monitors for
complete theme changes. If the contents of the
icon theme change, however, the texture cache
isn't properly invalidated.
This manifests itself as a randomly reproducible
bug when installing an app; the app icon may be
the fallback forever, or as long as something else
updates the icon theme.
Watch for the GtkIconTheme:changed signal, and
evict the texture cache when the theme changes.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/661
Images are loaded either with a supplied fixed size, or using the "native"
dimensions of the file. When creating a content image from the loaded data,
we currently simply apply this directly to the preferred size.
This works usually fine: GdkPixbuf will always keep the aspect ratio, so
if only one dimension is provided, the other will be adjusted accordingly:
Loading a 200x200 image with a requested size of (100, -1) will result in
a 100x100 content image.
There is a catch though: GdkPixbuf will only scale *down* to the requested
size, no up. That is, loading a 100x100 image with a requested size of
(200, -1) will result in a 100x100 pixbuf. But as we assume that the pixbuf
size matches the requested size, the image content ends up with 200x100.
Fix this by explicitly handling the case where only one size was supplied,
and make the other dimension take the aspect ratio into account
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/525
With StImageContent, the meaning of passing -1 as size parameter changed
from "load the image at its preferred size" to "abort the session". It
is therefore no longer possible to just load the image and then have it
scaled by applying a CSS size to the texture's parent.
Setting the size from CSS is useful though, so to still allow that, fall
back to the actor's size (which can be determined by the style).
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1027
It might happen that the target clutter actor that we return on call
of st_texture_cache_load_sliced_image might be destroyed while the
loading task is still running. To protect from this, let's connect
to "destroy" signal and when this happens we use a cancellable to
stop the task.
This allows to safely reuse the return value of this function to
cancel the execution and avoiding that load_callback is called
even for a request that is not anymore under our control.
https://bugzilla.gnome.org/show_bug.cgi?id=765011
When loading an actor for a sliced image actor, we can now use the
REQUEST_CONTENT_SIZE request-mode for the actor since we the content image
has now a predictable size and thus we can be sure that the size will be applied
taking care of the resource scale.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/5
Instead of just passing a scale when getting a cached icon, pass both a
'paint_scale', the scale of which the icon will be painted on the
stage, and a 'resource_scale', the scale of the resource used for
painting.
In effect, the texture size will use the scale 'paint_scale * resource_scale'
in a ceiled value while the size of the actor will use 'paint_scale' when
determining the size.
this would load a bigger texture, but the downscaling would keep the visual
quality.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/5https://bugzilla.gnome.org/show_bug.cgi?id=765011
