The documentation was suggesting that using G_APPLICATION_IS_SERVICE
would automatically set an inactivity timeout (ie: app stays around for
a while after the use count drops to zero).
In reality, it only adds an initial 10 second wait for the first
activation message to arrive after which it uses the normal inactivity
timeout mechanism.
Implement the g_network_monitor_can_reach_async() rather than falling
back to the default implementation, which calls the sync version (not
in a thread).
https://bugzilla.gnome.org/show_bug.cgi?id=694181
Enumerate the GSocketConnectable before checking for a default route.
For some connectable types this will involve a DNS lookup. This will
elminate false positives for hosts behind a VPN since DNS lookup will
fail if the VPN is not connected.
https://bugzilla.gnome.org/show_bug.cgi?id=694181
If the resolver reloads (ie, if /etc/resolv.conf changes),
GNetworkAddress needs to re-resolve its addresses the next time it's
enumerated. Otherwise hosts that have different IP addresses inside
and outside a VPN won't work correctly if you hold on to a
GNetworkAddress for them for a long time.
https://bugzilla.gnome.org/show_bug.cgi?id=694181
In the case that the "HOME" environment variable is set (as it is under
normal circumstances), we don't really need to be opening /etc/passwd.
For historical reasons (ie: how we used to ignore $HOME) and due to the
grouping of many unrelated things together (reading username, hostname,
home directory, tmpdir, etc.) into one function we were still opening
/etc/passwd in g_get_home_dir(), even if $HOME was set.
Since earlier commits removed code from it, all that remains in
g_get_any_init_do() is the logic for dealing with $HOME and reading the
password database.
We now split the logic to deal with $HOME into g_get_home_dir(). With
only the password database functionality remaining, g_get_any_init_do()
is renamed to g_get_user_database_entry() and modified not to set global
variables but rather return a struct. If g_get_home_dir() cannot find
$HOME, it falls back to calling g_get_user_database_entry() and using
the home directory from there.
Use of the 'g_utils_global' lock is further reduced by using
g_once_init_enter() to protect the critical sections in each of
g_get_user_database_entry() and g_get_home_dir().
Finally, the g_get_user_name() and g_get_real_name() functions are
modified to use the new regime.
https://bugzilla.gnome.org/show_bug.cgi?id=693204
Some code was directly calling g_get_any_init() and then expecting to be
able to use the static 'g_home_dir' variable directly. Change these
over to g_get_home_dir() instead.
https://bugzilla.gnome.org/show_bug.cgi?id=693204
This is a source-compatible change and only breaks ABI with respect to
truly ancient binaries (and those binaries are already broken for other
reasons).
Back in the day, functions like g_get_user_name() used to return strings
in the system codepage instead of utf8 (as they do today).
It was decided at some point to change these functions to return utf8,
breaking source compatibility but keeping ABI compatibility. This was
done by exporting new symbols with names like g_get_user_name_utf8() and
using a #define of the old name over to the new name (so that newly
compiled code would link against the _utf8 version, but old binaries
would continue to use the non-utf8 variant).
Meanwhile, glib has undergone several ABI breaks on Windows since, so
those old binaries don't work anymore.
Start to clean up this mess by removing the #define renaming. New
binaries calling g_get_user_name() will now link against
g_get_user_name() and it will return utf8.
We must keep the functions like g_get_user_name_utf8() for binary
compatibility with recently built programs (ie: ones built with the
renaming). Nobody should have ever been calling these directly and of
course they can return utf8, so just add them as internal wrappers in the
.c file and declare them _GLIB_EXTERN there.
One day, if we feel like breaking Windows ABI again, we can finish the
cleanup by dropping the wrappers. There is some talk of introducing
something like 'ABI compatible for two years' and this change would be
compatible with such a regime.
https://bugzilla.gnome.org/show_bug.cgi?id=693204
If a GNetworkAddress is created with a hostname like "fe80::xxx%em1",
make sure that the scope_id corresponding to "em1" is present in the
GSocketAddresses it returns when used as a GSocketConnectable.
https://bugzilla.gnome.org/show_bug.cgi?id=684404
Add GSimpleProxyResolver, for letting people do static proxy
resolution, and to use as a base class for other resolvers (such as
GProxyResolverGnome).
https://bugzilla.gnome.org/show_bug.cgi?id=691105
Add a proxy-resolver property to GSocketClient, to allow overriding
proxy resolution in situations where you need to force a particular
proxy rather than using the system defaults.
https://bugzilla.gnome.org/show_bug.cgi?id=691105
This is a GLib reimplementation of dbus_address_escape_value().
It's useful if you want to construct a D-Bus address from pieces:
for instance, if you have a listening Unix socket whose path is known,
and you want to connect a D-Bus peer to it.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=693673
Reviewed-by: Colin Walters <walters@verbum.org>
[amended to add Since: 2.36 as per review]
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
If we don't connect to the control proxy's 'g-signal' signal, we won't have
'object-added' or 'object-removed' signals. So, connect to the 'g-signal' not
only when there already is a name-owner, but always.
https://bugzilla.gnome.org/show_bug.cgi?id=693285
We have some testcases that assert that type modules are unloaded after
the last reference on them is dropped. Comment out those asserts now
that we turned the last unref into a no-op.
https://bugzilla.gnome.org/show_bug.cgi?id=693351
Experimentally disable the ability to unload dynamic types by refusing
to drop the last reference on types (effectively turning the type
unloading into dead code).
The plan is to leave things like this for a stable cycle and only
proceed with removing the code if we are sure that there are no
unforeseen problems.
https://bugzilla.gnome.org/show_bug.cgi?id=693351
Some compilers have support for atomic operations, but do not
define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4. Instead of checking
for this define, we check for __sync_bool_compare_and_swap and
define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4 if the compiler doesn't
define it.
https://bugzilla.gnome.org/show_bug.cgi?id=682818
