Avoid acquiring the lock on the instance on the case of deserialising a
child. We know that it is safe to do this unlocked because a serialised
child will never become unserialised.
Closes#626320
Make g_get_user_data_dir() return the CSIDL_LOCAL_APPDATA folder on
Windows, and not CSIDL_PERSONAL. On Windows 7, that corresponds to the
subfolders AppData\Local vs. Documents under the profile ("home")
folder. This matches what Qt does, for instance, and has been widely
requested.
Also make g_get_user_config_dir() return this and not the (roaming)
CSIDL_APPDATA folder. The reason for this change is that it would be
surprising and hard to justify if g_get_user_data_dir() returned the
local application data folder while g_get_user_config_dir() would
return the roaming one. Nothing in the function names or the XDG specs
suggests that any roaming vs. local dichotomy would be involved.
Document the new semantics and the fact that these two functions now
return the same directory on Windows.
Note that in reality, code that really truly wants to support Windows
as well as possible probably will not use these GLib functions anyway,
but Win32 APIs directly to be sure what it is doing...
Should hopefully satisfy complaints in bug #620710 and related bugs.
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).
Make g_variant_byteswap() merely return a new reference on the given
value in the event that we know that byteswapping will have no effect
(ie: types which have no alignment requirement).
This fixes a somewhat complicated interaction between GVariant,
GSettings and GVDB on big endian machines: GSettings assumes that it
can unref values returned from GVDB without losing access to the
underlying data. This only works if the underlying data is in the
mapped file -- not a freshly-allocated buffer that GVariant byteswapped
into.
Adds a new function g_main_context_invoke() (and _full() variant).
This function takes a main context, a function and a user_data. If the
main context is already acquired in the current thread, the function is
invoked directly. If the main context is the default main context of
the current thread and it can be acquired then the function is invoked
directly while the context is owned. Otherwise, the function is
scheduled as an idle on the context.
No functionality changes here.
Vastly simplify the algorithm for calculating the day of the week.
Fix the documentation (which is incorrectly stating that 1 means
Sunday) and clarify that the number we return is in line with ISO 8601
week day numbering.
Emmanuele suggested adding G_GNUC_WARN_UNUSED_RESULT to all of the
g_date_time_add_* functions to help deal with the situation where people
may mistakenly believe that these functions are inplace modifiers.
Using the internal pcre has the side effect of exposing gregex.c to
glib.h. When we use the system one, we lose that, so we need to
explicitly include the things we use (glist, gatomic, etc..)
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
The current msgctxt string 'GDateTime" lead to the unability to
differentiate between the full and abbreviated name for May.
Therefore, the msgctxt strings have been changed to
'full month name'
'abbreviated month name'
'full weekday name'
'abbreviated weekday name'
This is a string change, but all translations have been updated
using an sed script.
Bug 629429
This is a vtable structure and very likely the user has allocated it in
static storage and wants it to be const. Since we never modify it, no
harm is done to us to have it const.
Closes bug #629328.
Use Proleptic Gregorian calendar instead of the Julian calendar
as the internal representation.
https://bugzilla.gnome.org/show_bug.cgi?id=50076
Signed-off-by: Emmanuele Bassi <ebassi@linux.intel.com>
Previously, the format string was iterated many times by
walking to the given offset in the string repeatedly.
This patch instead walks the string using g_utf8_next_char().
Additionally, the character for lookups was a char and could
loose content. This uses gunichar instead.
https://bugzilla.gnome.org/show_bug.cgi?id=50076
These were left over from when the inline functions where implemented
as macros. They are no longer needed and where clashing with the
global __year anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=50076
