This is what we used to get through the Net/FallbackIcontheme
setting. Nobody has ever set this setting to a different value,
and people have come to rely on GTK+ applications getting their
icons this way.
When doing fallback for symbolic icons, we first shorten
the name at dashes while preserving the -symbolic suffix.
But after exhausting that, we should also try stripping
the suffix.
https://bugzilla.gnome.org/show_bug.cgi?id=708163
When loading a symbolic icon, g_file_get_contents() is currently used
with the icon pathname, to load its SVG data. This won't work when the
icon is not a local file, for instance when a symbolic icon is loaded
from a GFileIcon with a GResource path.
Fortunately GtkIconInfo already holds a GFile, so we can just use
g_file_load_contents() to load the data instead.
https://bugzilla.gnome.org/show_bug.cgi?id=709056
If an icon is in a Fixed or Threshold directory we normally don't
scale it. However, in the case of HiDPI scaling we *do* want to
scale it, to avoid different layouts in Lo/HiDPI. We look up whatever
the size of the icon would have been in LoDPI and scale to that
in the no-scaling case, thus getting the same layout as the
unscaled case.
https://bugzilla.gnome.org/show_bug.cgi?id=708384
GdkPixbuf will fail returning %NULL if we try to scale a pixbuf to (0, 0),
which will then trigger an assertion in gtk_icon_info_load_icon_finish();
we never want a scale of 0, so ensure it is at least 1.
https://bugzilla.gnome.org/show_bug.cgi?id=708384
Due to the work on gdk_cursor_new_from_surface (commit b2113b73),
get_cursor_for_pixbuf() in GdkDisplayClass was converted to
get_cursor_for_surface(), which means the GDK Win32 backend needs to be
updated for the code to build and run on Windows, plus some function
prototypes and declarations/calls need to be updated as well.
https://bugzilla.gnome.org/show_bug.cgi?id=705980
For backwards compat support we don't want old implementations not
supporting scaling to see the new scaled directories, so move these
to a separate list.
The rsvg loader now restricts what external files it will
allow to load from an svg. Thus our xinclude trick doesn't work
anymore. To work around that, embed the payload in a data: uri.
This is somewhat ugly, but the best we could come up with.
When an icon is requested as symbolic, our generic fallback algorithm
uses fullcolor icons when the specified icon name is not found, treating
the "-symbolic" suffix as another component of the icon name.
Change the algorithm to check beforehand if the icon is symbolic, remove
the suffix if so, and re-add it at the end for all the generated icon
names.
https://bugzilla.gnome.org/show_bug.cgi?id=680926
We checked for G_IS_LOADABLE_ICON() before GDK_IS_PIXBUF().
Since we made GdkPixbuf implement GLoadableIcon, the special case for
pixbufs is never used, and the much much slower GLoadableIcon path is
taken instead. Move the GdkPixbuf one to be first to fix that.
https://bugzilla.gnome.org/show_bug.cgi?id=705320
We've recently a number of classes wholly. For these cases,
move the headers and sources to gtk/deprecated/ and adjust
Makefiles and includes accordingly.
Affected classes:
GtkAction
GtkActionGroup
GtkActivatable
GtkIconFactory
GtkImageMenuItem
GtkRadioAction
GtkRecentAction
GtkStock
GtkToggleAction
GtkUIManager
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
