This new API allows requesting multiple pieces of information about a
particular action in one go and also simplifies the burden for
GActionGroup implementations -- they need not implement all the separate
APIs now.
* Represents an immutable reference counted block of memory.
* This is basically the internal glib GBuffer structure exposed,
renamed, and with some additional capabilities.
* The GBytes name comes from python3's immutable 'bytes' type
* GBytes can be safely used as keys in hash tables, and have
functions for doing so: g_bytes_hash, g_bytes_equal
* GByteArray is a mutable form of GBytes, and vice versa. There
are functions for converting from one to the other efficiently:
g_bytes_unref_to_array() and g_byte_array_free_to_bytes()
* Adds g_byte_array_new_take() to support above functions
https://bugzilla.gnome.org/show_bug.cgi?id=663291
Add GNetworkMonitor and its associated extension point, provide a base
implementation that always claims the network is available, and a
netlink-based implementation built on top of that that actually tracks
the network state.
https://bugzilla.gnome.org/show_bug.cgi?id=620932
Instead of:
warning: ‘g_variant_get_gtype’ is deprecated (declared at ../../gobject/glib-types.h:242): Use '((GType) ((21) << (2)))' instead [-Wdeprecated-declarations]
show:
warning: ‘g_variant_get_gtype’ is deprecated (declared at ../../gobject/glib-types.h:242): Use ''G_VARIANT_GET_TYPE'' instead [-Wdeprecated-declarations]
Also, document the macro-expansion problem in the
G_GNUC_DEPRECATED_FOR docs
Allow passing --identifier-prefix and --symbol-prefix to glib-mkenums,
with the same meanings as in g-ir-scanner, to allow fixing up the enum
name parsing globally rather than needing to add a /<* *>/ override to
each enum.
https://bugzilla.gnome.org/show_bug.cgi?id=661797
The documentation for maybe types failed to mention 'a' as one of the
types that was handled with a single pointer for which NULL means
"nothing". Correct that omission.
Problem caught by Shaun McCance.
We clean up the detection of if we should do 'real' atomic operations or
mutex-emulated ones with the introduction of a new (public) macro:
G_ATOMIC_LOCK_FREE. If defined, our atomic operations are guaranteed to
be done in hardware.
We need to use __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4 to determine if our
compiler supports GCC-style atomic operations from the gatomic.h header
because we might be building a program against GLib using a different
set of compiler options (or a different compiler) than was used to build
GLib itself.
Unfortunately, this macro is not available on clang, so it has currently
regressed to using the mutex emulation. A bug about that has been
opened here:
http://llvm.org/bugs/show_bug.cgi?id=11174
Adds g_key_file_ref and g_key_file_unref, to be used by a future
GKeyFile boxed type for language bindings.
Based on the patch by Christian Persch and Emmanuele Bassi.
Author: Christian Persch
Signed-off-by: Johan Dahlin
Signed-off-by: Giovanni Campagna
https://bugzilla.gnome.org/show_bug.cgi?id=590808
Add functions for manipulating the environment under which a
GAppLaunchContext will launch its children, to avoid thread-related
bugs with using setenv() directly.
FIXME: win32 side isn't implemented yet
https://bugzilla.gnome.org/show_bug.cgi?id=659326
When spawning a child process, it is not safe to call setenv() before
the fork() (because setenv() isn't thread-safe), but it's also not
safe to call it after the fork() (because it's not async-signal-safe).
So the only safe way to alter the environment for a child process from
a threaded program is to pass a fully-formed envp array to
exec*/g_spawn*/etc.
So, add g_environ_getenv(), g_environ_setenv(), and
g_environ_unsetenv(), which act like their namesakes, but work on
arbitrary arrays rather than working directly on the environment.
http://bugzilla.gnome.org/show_bug.cgi?id=659326
Some code using GLib (gnome-keyring-daemon, for example) assumes that
they can catch signals by masking them out in the main thread and
calling sigwait() from a worker.
The problem is that our new worker thread catches the signals before
sigwait() has a chance and the default action occurs (typically
resulting in program termination).
If we mask all the signals in our worker, then this can't happen.
With search gaining traction as being the preferred way to locate
applications, the existing .desktop file fields meant for browsing
often produce insufficient results.
gnome-control-center introduced a custom X-GNOME-Keywords field for
that purpose, which we plan to support in gnome-shell as well.
https://bugzilla.gnome.org/show_bug.cgi?id=661763
Switch GCond to using monotonic time for timed waits by introducing a
new API based on monotonic time in a gint64: g_cond_wait_until().
Deprecate the old API based on wallclock time in a GTimeVal.
Fix up the gtk-doc for GCond while we're at it: update the examples to
use static-allocated GCond and GMutex and clarify some things a bit.
Also explain the rationale behind using an absolute time instead of a
relative time.
Unlike G_GNUC_... macros, the new G_DEPRECATED[_FOR] are
meant as abstractions that work with different compilers.
Using a new name also lets us restrict it to 'must be placed
before the declaration', which works with more compilers.
https://bugzilla.gnome.org/show_bug.cgi?id=661438
Add g_main_context_ref_thread_default(), which always returns a
reffed GMainContext, rather than sometimes returning a (non-reffed)
GMainContext, and sometimes returning NULL. This simplifies the
bookkeeping in any code that needs to keep a reference to the
thread-default context for a while.
https://bugzilla.gnome.org/show_bug.cgi?id=660994
