An optional OutputScale integer key has been added to index.theme
subdirs description, so icon themes may provide icons that are
more suitable to render at a (typically 2x) integer upscaled
resolution. This way it is possible to make eg. a 16x16@2x icon has a
real size of 32x32, but contains a similar level of detail to the
16x16 icon so things don't look any more cluttered on high-dpi
screens.
The pixbuf lookup has changed so it prefers a minimal scale change
that yields the minimal real size difference, so if looking up for
a 16x16 icon at 2x, it would first prefer 16x16@2x, then 32x32, and
then any other icon that's closest to match
There is now *_for_scale() variants for all GtkIconTheme ways
to directly or indirectly fetch a GdkPixbuf.
This is based on code by Carlos Garnacho with changes by Alexander
Larsson
By delaying the emission to an idle we avoid a lot of tricky
reentrancy issues. For instance, a normal gtk_icon_theme_choose_icon()
call could in very rare cases (when a user updated an icon theme) emit
a signal which could affect the icon currently being looked up. This
kind of reentrancy is very hard to test against, especially when it is
so rare, so we're better of avoiding it.
There is no real value to get the change signal directly anyway. All
it can do is affect which icon is rendered the next frame, and we will
handle the queued emission before rendering. Not to mention that icon
theme change detection is polled anyway, so it is already delayed.
https://bugzilla.gnome.org/show_bug.cgi?id=694755
When we're reloading the theme in ensure_valid_themes (due to noticing
that a theme dir has changed) we need to also clear the icon cache
as it will not be valid for the new theme.
We already do this in do_theme_change(), but ensure_valid_themes()
was missing this.
https://bugzilla.gnome.org/show_bug.cgi?id=702598
The icon data in GttkIconInfo->data is currently owned by the
IconThemeDir->icon_data hashtable. However, on e.g. a theme change
blow_themes() destroys the dirs and thus the data, meaning any
outstanding GtkIconInfo points to stale data.
We solve this by adding a refcount to GtkIconData and reffing it
from GtkIconInfo.
https://bugzilla.gnome.org/show_bug.cgi?id=702598
icon_info_dup() is now called also for GtkIconInfos that already have
a pixbuf, so we must make sure that we correctly carry that from
the original icon_info to the copy.
If you tried to lookup an icon that was not emblemed, and then looked up
an emblemed icon with the same base, we would override the iconinfo adding
the emblems inline. Later, when the icon finished rendering, inside
gtk_icon_info_load_icon_finish, we would copy the result from the duplicate
(which did not include the emblem infos), but the icon would still fail the
assertion, because emblems infos are present but emblem_applied is false
(they were not requested in the first place!).
Solve this by avoiding the overwrite on a cached iconinfo, and instead duplicate
the iconinfo before adding the emblems. It is expected that another layer
of caching (such as StTextureCache in gnome-shell) will take care of avoiding
multiple rendering of the same icon+emblem combination.
https://bugzilla.gnome.org/show_bug.cgi?id=694968
gtk_icon_info_copy and gtk_icon_info_free are deprecated for
the corresponding GObject methods.
We set correct transfer markup for the GtkIconInfo returning methods
to fix the introspection of them.
gtk_icon_info_load_symbolic_for_context_async had the wrong method
name in its documentation block.
This is necessary in order to have async operations on it.
All the old copy/free functions keeps working, and g_boxed_copy on a GObject
also works, so this should be mostly compatible, but techncally its a minor
ABI break since the GType changes fundamental type. Changes like this has
happened before though, like with GVariant becomming its own fundamental
type.
https://bugzilla.gnome.org/show_bug.cgi?id=693802
With the previous commit all loads of the same icon will share a single
GtkIconInfo, which typicallty means the pixbuf is shared via Info->pixbuf.
However, atm we don't share symbolic icons, which causes these to be re-read
and re-parsed every time. This is especially bad if the icon is used many times
in some form of list. So, we cache the pixbufs and reuse them.
https://bugzilla.gnome.org/show_bug.cgi?id=689081
In order to avoid loading and keeping around the same icon multiple times
we keep a cache of all outstanding GtkIconInfo objects for a given theme.
Additionally we return to the app not the normal pixbuf from the info,
but rather a proxy copy of it sharing the same data, but no extra
reference. This allows us to track when the app is no longer using
the pixbuf, and we can thus ensure that the GtkIconInfo in the cache
stays around for at least as long as the pixbuf is alive.
When the app unrefs the pixbuf we put the Info on a short LRU list
to keep it alive a bit longer, in case the app needs it in a short
while.
https://bugzilla.gnome.org/show_bug.cgi?id=689081
Right now we support loading and recoloring symbolic GFileIcons, but
only if the underlying GFile has a local path. This breaks when the
GFileIcon is loaded from a GResource, which is a reasonable option for an
application that wants to ship a custom symbolic icon.
This patch changes GtkIconInfo to store a GFile together with the file
path, and changes the symbolic icon lookup code to use the GFile URI,
which transparently makes the code work also for GResources.
https://bugzilla.gnome.org/show_bug.cgi?id=687059
If the symbolic icon has other size than 16x16, the embedder
SVG that overrides colors would still force that size, resulting
in clipping instead of resizing. So fetch the original pixbuf
size the first time a symbolic icon is requested for a GtkIconInfo,
and use that size for the embedder SVG so it can be scaled properly
afterwards.
https://bugzilla.gnome.org/show_bug.cgi?id=677567
gtk_icon_info_load_symbolic checks for the existance of a filename parameter
so it can include it along with the stylesheet. We don't set the filename
parameter when creating the info for a GFileIcon, for some reason.
https://bugzilla.gnome.org/show_bug.cgi?id=676356
Symbolic icons use a "-symbolic" suffix to distinguish themselves from
highcolor variants. Note that the dash character here has a different
meaning than the specificity level defined in the icon-naming-spec [1],
as it identifies a property of the icon itself.
Since they might be provided by a parent theme (e.g. the HighContrast theme
relies on the gnome icon theme for them), when we are looking up one we
should first escape the generic icon inheritance mechanism defined in the
icon-naming-spec [1], and privilege a symbolic icon, if it exists in a
parent theme, before applying the inheritance evaluation.
This fixes symbolic icons not working properly when used in the
HighContrast theme with the GTK_ICON_LOOKUP_GENERIC_FALLBACK flag set.
[1]
http://standards.freedesktop.org/icon-naming-spec/latest/ar01s03.htmlhttps://bugzilla.gnome.org/show_bug.cgi?id=674806
Thanks to Kean Johnston for pointing this out.
There are a few places in GTK that use "struct stat",
and then g_stat(), rather than using GStatBuf.This breaks things on
Windows. Since the size of struct stat can vary depending on other
flags specified, this has the potential to cause overwrites and is
trivial to fix.
Based on patch submitted by Kean Johnston
I was hunting a memory leak and couldn't find it; at least I'm
pretty sure all of these are OK. But document things better
for the future.
Also use g_hash_table_replace in one more case for consistency.
https://bugzilla.gnome.org/show_bug.cgi?id=649457
This change does not introduce any functionality change, mostly
cosmtic cleanups, like re-linebreak when introduced annotations messed
up indentation or whitespace errors fixes.
