We really shouldn't use <unknown> when we can perfectly easily
get argv0 out of /proc. This avoids people having to pass argv
down into gtk_init/g_option_context_parse etc., which is important
because GTK+ uses it to initialize the WM_CLASS, which in turn
GNOME Shell consumes for application tracking.
https://bugzilla.gnome.org/show_bug.cgi?id=644309
g_variant_new("as", NULL); now gives an empty array of strings, for
example.
This was documented as working already, but was never actually
implemented (due to the fact that it muddies the water when considering
maybe types). It's being implemented now because its convenience to
programmers exceeds any damage done to the conceptual purity of the API.
One new GUnicodeBreak enum member. Three new GUnicodeScript members,
and one member renamed to fix a typo.
Tests, docs, and scripts are updated. PCRE update still needed.
Also add some test cases to test/hostutils for that and a few other
things, and make the test program just act as an ASCII/unicode
hostname converter rather than a test program if it's run with an
argument.
https://bugzilla.gnome.org/show_bug.cgi?id=633350
Add some helpers for freeing a linked list along with its elements by
providing a GDestroyNotify to call on each of them.
Add a test.
Based on a patch from Cosimo Cecchi.
One of the GVariant test cases allocates a pair of character arrays on
the stack and then passes them to functions that assume that they will
be aligned to a multiple of two.
This is not the case for some versions of GCC (4.0.3 on PowerPC).
If a DateTime gets modified to cross the DST state from its previous
state then we want to update the DateTime to compensate for the new
offset.
In other words, if we have a DateTime defined as:
DateTime({ y: 2009, m: 8, d: 15, hh: 3, mm: 0, tz: 'Europe/London' });
and we add six months to it, the hour must be changed to 60 minutes
behind, as the DST comes into effect.
https://bugzilla.gnome.org/show_bug.cgi?id=50076
Otherwise we'll have to do:
dt = g_date_time_new_full (Y, M, D, h, m, s, tz);
tmp = g_date_time_add_usec (dt, usec);
g_date_time_unref (dt);
dt = tmp;
With its additional allocations.
https://bugzilla.gnome.org/show_bug.cgi?id=50076
Timezone handling is complicated. Really complicated.
In order to simplify it a little bit, we need to expose the GTimeZone
structure.
First of all, we allow creating time zone information directly from the
offset and the DST state, and then pass it to the g_date_time_new_full()
constructor. We also need to clean up the mess that is UTC-vs.-localtime
for the other constructors.
We also allow creating a GTimeZone from the Olson zoneinfo database
names; a time zone created like this will be "floating": it will just
reference the zoneinfo file - which are mmap()'ed, kept in a cache and
refcounted. Once the GTimeZone has been associated with a GDateTime, it
will be "anchored" to it: the offset will be resolved, as well as the
DST state.
https://bugzilla.gnome.org/show_bug.cgi?id=50076
