Since this feature is so utterly automake-centric, we may as well be
using the same terminology as automake itself (ie: although it's
BUILT_SOURCES, it's DIST_EXTRA, not DISTED).
Also add some comments to the enum explaining that these terms are
really corresponding directly to the automake terms.
https://bugzilla.gnome.org/show_bug.cgi?id=549783
Add support for serialising a GIcon to a GVariant and deserialising the
result back to a GIcon.
This solves a number of problems suffered by the existing to_string()
API, primarily these:
- not forcing the icon to be a utf8 string means that we can
efficiently encode a PNG (ie: just give the array of bytes)
- there is no need to ensure that proper types are loaded before using
the deserialisation interface. 'Foreign' icon types will probably
emit a serialised format the deserialises to a GBytesIcon.
We additionally clearly document what is required for being a consumer
or implementation of #GIcon.
Further patches will be required to GdkPixbuf and GVfsIcon to bring
their implementations in line with the new rules (essentially: introduce
implementations of the new serialize() API).
https://bugzilla.gnome.org/show_bug.cgi?id=688820
Very many testcases, some GLib tools (resource compiler, etc) and
GApplication were calling g_type_init().
Remove those uses, as they are no longer required.
https://bugzilla.gnome.org/show_bug.cgi?id=686161
==2428== 256 bytes in 1 blocks are definitely lost in loss record 591 of 604
==2428== at 0x4005CD2: realloc (vg_replace_malloc.c:476)
==2428== by 0x40571A5: g_realloc (gmem.c:181)
==2428== by 0x4075287: g_string_maybe_expand (gstring.c:395)
==2428== by 0x40760D8: g_string_insert_c (gstring.c:1049)
==2428== by 0x4074D41: g_string_append_c_inline (gstring.h:153)
==2428== by 0x4075B3C: g_string_append_uri_escaped (gstring.c:822)
==2428== by 0x41A46AC: g_icon_to_string_tokenized (gicon.c:164)
==2428== by 0x41A498F: g_icon_to_string (gicon.c:252)
==2428== by 0x8049E1A: test_g_icon_serialize (g-icon.c:222)
Bug #628331.
