We need to use a GdkPixbufLoader instead of the straightforward
gdk_pixbuf_new_from_file(), since we want to load the image already
scaled if possible - e.g. if it's an SVG file.
https://bugzilla.gnome.org/show_bug.cgi?id=726907
It's possible that FBO creation fails due to hw limits or the
driver not exposing the EXT_framebuffer_object extension.
In that case, just give up on creating square icons.
https://bugzilla.gnome.org/show_bug.cgi?id=724977
While we were relying on gtk_icon_info_load_icon and friends being
thread-safe, there was no such guarantee, and recent caching that
was added to GTK+ made it non-threadsafe. To replace it, _async()
variants of the icon loading code were added that are thread-safe.
Use those instead of using our own worker threads.
https://bugzilla.gnome.org/show_bug.cgi?id=692845
The AnimatedIcon does not have an API for controlling the animation but
relies on the :visible property changes to start and stop a timeout used
to update the frame.
This has the inconvenient of having a side effect when visible is set to
true multiple times, and is not really the API expected from such
component. Also, there is a race if it is displayed before the images
are loaded: there is no child yet and thus we get this._frame = NaN
which leads to a crash.
Switch to a play/stop API instead, and add a load event callback to the
TextureCache.load_slice_image to exactly know when we can start using
the images.
https://bugzilla.gnome.org/show_bug.cgi?id=687583
For textures loaded from files, the cache might hide image changes
by keeping the data of a previous version around indefinitely. For
instance AccountsService will notify of avatar changes, but as new
image is copied over the old one, we will continue to use the old
image data.
Install a file monitor for each file resource we load and clear
the corresponding data from the cache on changes, emitting the
new StTextureCache::texture-file-changed signal.
https://bugzilla.gnome.org/show_bug.cgi?id=679268
The current API assumes that image data loaded from files remains
valid during the life time of the shell. This assumption is mostly
valid for image files we provide ourselves (with the exception being
designers working on those files), but not necessarily for "external"
files - provide API to explicitly remove cached data associated with
a URI for those cases.
https://bugzilla.gnome.org/show_bug.cgi?id=679268
st_texture_cache_load_from_raw() enforces a square ClutterTexture,
resulting in the texture being stretched if the passed in image
data has a different width:height ratio.
Add padding in those cases as we already do when loading from pixbufs.
https://bugzilla.gnome.org/show_bug.cgi?id=683483
Reroute setting those properties to a GIcon. API users are expected
to create GIcon directly now.
The advantage is that from a StIcon you can now create a similar one
by accessing :gicon.
https://bugzilla.gnome.org/show_bug.cgi?id=682540
More than one outstanding request to the same URI should now be
deduplicated, and the framework is there if we want to cache async loaded
URIs as well
https://bugzilla.gnome.org/show_bug.cgi?id=672273
In the case that we don't have an icon corresponding to the gicon, it's
more than likely that the code calling load_gicon will know more about
what it wants as a fallback than the texture-cache itself. In fact -
we had a whole lot of dead code that would try to fall back, but never
did because we always returned a valid actor.
This was causing certain applications with invalid icons to not get the
fallback icon because an icon couldn't be found. Fix up the one place
where we don't have an explicit fallback icon codepath, and then stop
doing what we were doing.
https://bugzilla.gnome.org/show_bug.cgi?id=671656
grid_width and grid_height were inverted, which caused a crash
in GdkPixbuf code. This was never noticed because the animation
in the panel is a square.
https://bugzilla.gnome.org/show_bug.cgi?id=666606
For some reason, the texture cache decides to make a request and then look up
an icon in the icon theme. If it's valid, it just returns, fine, but if it
doesn't add the icon, it tries to undo the request, leaking an
AsyncTextureLoadData that isn't freed in the process.
https://bugzilla.gnome.org/show_bug.cgi?id=660968
Rather than have five or six structs allocated duplicating data,
just keep one and simplify the code considerably.
Again, part of my ongoing quest to merge St and Mx.
https://bugzilla.gnome.org/show_bug.cgi?id=660968
For GIcons we use g_icon_to_string() in the key, but the function
will return NULL if the icon cannot be serialized. As a result,
all non-serializable GIcons of the same size end up with the same
cache key - an example for this are contacts with avatars, which
currently all end up with the same image.
To fix, opt out of caching for GIcons which cannot be serialized.
https://bugzilla.gnome.org/show_bug.cgi?id=660585
Some functions in StTextureCache enforce square ClutterTextures,
even in cases where the underlying CoglTexture has a different
width:height ratio.
Add padding in those cases to keep the resulting image from being
stretched.
https://bugzilla.gnome.org/show_bug.cgi?id=643866
As of commit 34ce17c4b3, search results use large icons, or thumbnails
when available. To keep the amount of upscaling for the latter as small
as possible, request a large thumbnail size.
https://bugzilla.gnome.org/show_bug.cgi?id=645493
GThemedIcon expects the first name to be the most specific, and
will thus prefer it to later ones. We thus need to order the names
from the longer to the shorter.
https://bugzilla.gnome.org/show_bug.cgi?id=621707
g_themed_icon_new_with_default_fallbacks() does not do what we want
with symbolic icons; if the user's icon theme is not "gnome", then it
will end up preferring a non-symbolic icon from the higher-level theme
over a symbolic icon from gnome-icon-theme-symbolic.
If the shell requests a symbolic icon, and there is only a
non-symbolic icon available, that should be considered a programmer
error, just like requesting a non-existent icon name. So change the
code to only look up "-symbolic" names when drawing an
ST_ICON_SYMBOLIC icon.
https://bugzilla.gnome.org/show_bug.cgi?id=644142
Loading a pixbuf in a way that cairo can use it is a
pretty involved process that involves a lot of code, and pixel
fiddling.
This commit adds the mechanism to StTextureCache so we can reuse
the existing pixbuf handling code there, and also get caching.
https://bugzilla.gnome.org/show_bug.cgi?id=636976
We weren't freeing the whole pixbuf, nor were we the GList of
subpixbufs. Plug both of these leaks in the error handling path
and in the default case.
All of the unreffing/cleanup should happen in the GDestroyNotify
for the result, not some in the handler.
https://bugzilla.gnome.org/show_bug.cgi?id=636489
Add a "gicon" property so that a GIcon can be used instead of an
icon name, while still getting icon recoloring from the theme.
Also include a compatibility wrapper in libshell until GJS has
support for interface static methods.
https://bugzilla.gnome.org/show_bug.cgi?id=622451
Connect to the "changed" signal on the default icon theme, and
when it triggers:
- Evict all cached looked up icons from the StTextureCache
- Fake a style change on all StThemeContext; this will result
in StIcon looking up icons again.
https://bugzilla.gnome.org/show_bug.cgi?id=633866
Now that we're using St.Icon in the Javascript, there is no reason
to have separate st_texture_cache_load_icon_name() and
st_texture_cache_load_icon_name_for_theme(), instead just add
the StThemeNode argument to st_texture_cache_load_icon_name().
https://bugzilla.gnome.org/show_bug.cgi?id=633866
Add st_texture_cache_load_icon_name_for_theme() which, when loading a
symbolic icon, gets a #StIconColors from the theme node and uses that
to colorize the icon.
https://bugzilla.gnome.org/show_bug.cgi?id=633865
* Make sure all source files have a LGPL copyright header, and standardize
non-standard variations of the header to a common form.
* Check and update all copyright notices.
* Remove 'Written By:' lines. They are universally incomplete and
typically indicate only who started a particular file.
https://bugzilla.gnome.org/show_bug.cgi?id=634550
Icons can be loaded as St.Icon.SYMBOLIC, FULLCOLOR, APPLICATION or
DOCUMENT. The first will look for a symbolic equivalent, the second
looks for a full-color version (and does fallback, eg, from
"drive-harddisk-usb" to "drive-harddisk"). APPLICATION and DOCUMENT do
full-color icons without fallback (as specified by the icon spec).
And update various callers to use the right flags.
Based on a patch from Matt Novenstern.
https://bugzilla.gnome.org/show_bug.cgi?id=621311
* Use --warn-all, --warn-error
* Fix various broken gtk-doc
* Drop unused shell_get_event_related
* For header defines, we currently require them to end in _H to be skipped
* Drop the no-longer-necessary fix-meta-rectangle.py hack
* Move to the convention of using -private.h for headers that are,
well, private.
* Add shell-wm-private.h
This function reads a single image file which contains multiple
images internally.
The image file will be divided using @grid_width and @grid_height;
note that the dimensions of the image loaded from @path
should be a multiple of the specified grid dimensions.
https://bugzilla.gnome.org/show_bug.cgi?id=598349
- Specify a minimum version of clutter-1.2.0
- Switch clutter branch in the moduleset to master
- Replace deprecated cogl_texture/material_unref() with
cogl_handle_unref()
- Use cogl_clip_push_rectangle() rather than cogl_clip_push()
- Replace cogl_check_extension() with strstr - should be
accurate enough.
https://bugzilla.gnome.org/show_bug.cgi?id=610679
Rather than having ShellTextureCache know about the type of each
item it's caching, this lays the foundation for simply caching
arbitrary string -> CoglHandle.
https://bugzilla.gnome.org/show_bug.cgi?id=607500
For StWidget we want the ability to load raw CoglHandle references
rather than having a big pile of actors backing StWidget.
Several bits of StWidget expect to be able to synchronously load
textures; this is a crutch to support that until we can cleanly
make this asynchronous.
https://bugzilla.gnome.org/show_bug.cgi?id=607500
Brute force merge these two by essentially replacing St.TextureCache
with a (renamed) Shell.TextureCache.
One function was added for convenience, namely "st_texture_cache_load_file_simple".
St.TextureCache had a function to load a texture from a filename, and it
returned NULL on error but only half the callers actually checked this. This
function is better.
https://bugzilla.gnome.org/show_bug.cgi?id=607500
To each .c and .h file, add:
/* -*- mode: C; c-file-style: "gnu"; indent-tabs-mode: nil; -*- */
'gnu' is the default anyways for Emacs, but indent-tabs-mode is not,
so this sets things up to correspond to the policy of no-tabs.
http://bugzilla.moblin.org/show_bug.cgi?id=6467
Add GObject Introspection annotations to methods where needed, in
particular adding (transfer none) to return values that don't transfer
ownership.
st_texture_cache_get_actor() and st_texture_cache_get_texture()
are annotated as (transfer none) since they return a newly
created *floating* texture.
https://bugzilla.gnome.org/show_bug.cgi?id=591245
Import the core MxWidget/MxBin and their dependencies; we use the
namespace "St" (Shell Toolkit) because it is the same length as Mx
so enabling easy sharing of code, but makes it clear that this is
a friendly fork and not a literal import.
Based on a patch by Colin Walters <walters@verbum.org>
https://bugzilla.gnome.org/show_bug.cgi?id=591245
