With this we're not longer exporting the constructor headers, which means
we're not tying ourselves to a macro that might need special tweaking on
a compiler-by-compiler basis.
It's important to have strict rules for handling of whitespace in
translated strings in GSettings schema files so that the tools
extracting the messages will end up with the same messages as the
runtime calling gettext().
The rules are designed to be simple and unambiguous yet cover most
normal uses in a convenient way.
Those rules are as follows (with rationale):
- for <default> tags, the text content has its leading and trailing
whitespace stripped off, but internal whitespace is not modified in
any way.
This allows for slightly more flexible use of whitespace without
causing that whitespace to appear in the strings for translation.
- for <summary> and <description> tags, the content is split into
paragraphs. Paragraphs are separated by two or more sequential
newline characters. Each paragraph has its leading and trailing
whitespace removed and all other whitespace is normalised to a
single ascii space character. Finally, the paragraphs are rejoined,
inserting exactly two newlines between them.
This allows for longer explanations (particularly in the description
tag) using a natural format that, when normalised, will display
nicely in toolkits.
This patch implements the rules for <default> tags. The schema compiler
currently ignores <summary> and <description> tags.
First, correct a rather dubious case of accessing a GSettingsSchemaKey
after clearing it. This was technically okay because only the key name
was accessed (and it is not owned by the struct) but it looks very
wrong.
Second, have g_settings_backend_write() sink the passed in GVariant*.
Not all backends get this right, and I'm starting to like the pattern of
virtual function wrappers being responsible for sinking the parameters
that they are documented as consuming.
GValueArray was deprecated in bug 667228 and since we never change the
size of the array, it was kinda dumb to just GValueArray in the first
place.
https://bugzilla.gnome.org/show_bug.cgi?id=667228
Signed-off-by: David Zeuthen <davidz@redhat.com>
This is needed for thread-safety ... yes, it would have been better to
make get_object() return a full reference and have something like a
peek_object() method return a borrowed reference for C convenience
(only a single vfunc would have been needed). But such an ABI break is
too late now...
Signed-off-by: David Zeuthen <davidz@redhat.com>
It's hardly useful to bloat the resource data with blanks intended only
for human readability, so add a preprocessing option that uses xmllint --noblanks
to strip these.
Bug #667929.
Some platforms don't have the source-specific multicast sockopts, and
so would fail to compile. Fix that (and return an error if the caller
tries to use source-specific). Also clarify the docs a bit.
https://bugzilla.gnome.org/show_bug.cgi?id=668468
This lets you poke at resources in elf files and
standalone resource bundles. So far, only listing
and extracting resources is supported. The support
for elf files requires libelf.
g_settings_create_action() will create a GAction for the named key,
allowing it to be added to the action group of the application (so that
the setting can be directly manipulated from menus, for example).
https://bugzilla.gnome.org/show_bug.cgi?id=668279
glib-compile-schemas used to generate these. They're harmless and they
mean that no schemas are installed in a particular directory, so just
ignore them.
https://bugzilla.gnome.org/show_bug.cgi?id=656301
==13007== 173 bytes in 1 blocks are definitely lost in loss record 90 of 106
==13007== at 0x402AD89: malloc (vg_replace_malloc.c:236)
==13007== by 0x407DDBA: standard_malloc (gmem.c:85)
==13007== by 0x407E318: g_try_malloc (gmem.c:271)
==13007== by 0x40654DE: g_file_get_contents (gfileutils.c:756)
==13007== by 0x804A531: main (glib-compile-resources.c:580)
==13007== 521 (56 direct, 465 indirect) bytes in 1 blocks are definitely lost in loss record 100 of 106
==13007== at 0x402AD89: malloc (vg_replace_malloc.c:236)
==13007== by 0x407DDBA: standard_malloc (gmem.c:85)
==13007== by 0x407E160: g_malloc (gmem.c:159)
==13007== by 0x4091D8D: g_slice_alloc (gslice.c:1003)
==13007== by 0x40674A1: g_hash_table_new_full (ghash.c:676)
==13007== by 0x804B252: gvdb_hash_table_new (gvdb-builder.c:76)
==13007== by 0x43C66B2: (below main) (libc-start.c:226)
g_bus_get_finish() and g_bus_get_sync() both document that the returned
object will usually have exit-on-close set to TRUE, but the property's
documentation specified that its default is FALSE. While that's
technically true from a GObject perspective, it's not accurate from the
API user's perspective.
https://bugzilla.gnome.org/show_bug.cgi?id=668163
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: David Zeuthen <zeuthen@gmail.com>
Initial underscores are used in c identifier to make them private,
for instance in Gtk+. However, we don't want to have this in the
resource section name, that just looks ugly.
Apparently IPV6_JOIN_GROUP and IPV6_LEAVE_GROUP are more portable than
IPV6_ADD_MEMBERSHIP and IPV6_DROP_MEMBERSHIP. (Windows and Linux have
both, but OS X only has the latter.)
struct sin6_addr has two additional fields that struct sin_addr
doesn't. Add support for those to GInetSocketAddress, and make sure
they don't get lost when converting between glib and native types.
https://bugzilla.gnome.org/show_bug.cgi?id=635554
If a class implements GAsyncInitable, and its parent also implements
it, then the subclass needs to call its parent's init_async() before
running its own. This was made more complicated by the fact that the
default init_finish() behavior was handled by the wrapper method
(which can't be used when making the super call) rather than the
default implementation itself. Fix that.
https://bugzilla.gnome.org/show_bug.cgi?id=667375
When the flags enum only has the default NONE = 0 entry, glib-mkenums
creates an enum type for it, not a flags type. Add an annotation to the
enum to ensure the correct GType is created.
Bug #667938.
GResource is a bundle of files combined into a single binary blog.
The API lets you access the files the resource contains by
using resource paths. You can also register resources with a
global list and access these globally in a merged resource namespace.
The normal way this is used is to link in the resources into your
application/library and have it be automatically registred.
Resources are compiled from an xml description using
glib-compile-resources.
This is implemented by with statfs_buffer.f_bavail (free blocks
for unprivileged users) as a default way to retrieve real free space.
Based on a patch by Marcus Carlson, bug 625751.
g_socket_receive_with_blocking() and g_socket_send_with_blocking claim
to return -1 in error, their return type is gssize, and yet they
return FALSE if the initial g_return_val_if_fail() call fails.
https://bugzilla.gnome.org/show_bug.cgi?id=667226
==24706== 52 bytes in 1 blocks are definitely lost in loss record 7,248 of 13,092
==24706== at 0x4A074CD: malloc (vg_replace_malloc.c:236)
==24706== by 0x70E9F5F: standard_malloc (gmem.c:85)
==24706== by 0x70E9FE8: g_malloc (gmem.c:159)
==24706== by 0x71018EC: g_slice_alloc (gslice.c:1003)
==24706== by 0x710192B: g_slice_alloc0 (gslice.c:1029)
==24706== by 0x7068526: g_type_create_instance (gtype.c:1872)
==24706== by 0x705067B: g_object_constructor (gobject.c:1835)
==24706== by 0x704FE47: g_object_newv (gobject.c:1699)
==24706== by 0x7050612: g_object_new_valist (gobject.c:1816)
==24706== by 0x704F894: g_object_new (gobject.c:1531)
==24706== by 0x6F0F2F0: g_inet_address_new_from_bytes (ginetaddress.c:459)
==24706== by 0x6F5D703: remove_network (gnetworkmonitornetlink.c:256)
==24706== by 0x6F5DD80: read_netlink_messages (gnetworkmonitornetlink.c:386)
==24706== by 0x6F2D5CA: socket_source_dispatch (gsocket.c:2505)
==24706== by 0x70E1D45: g_main_dispatch (gmain.c:2513)
==24706== by 0x70E2A06: g_main_context_dispatch (gmain.c:3050)
==24706== by 0x70E2BE9: g_main_context_iterate (gmain.c:3121)
==24706== by 0x70E2CAD: g_main_context_iteration (gmain.c:3182)
==24706== by 0x6F60A05: g_application_run (gapplication.c:1599)
==24706== by 0x42D011: main (ephy-main.c:472)
https://bugzilla.gnome.org/show_bug.cgi?id=667098
Some of the GLib tests deliberately provoke warnings (or even fatal
errors) in a forked child. Normally, this is fine, but under valgrind
it's somewhat undesirable. We do want to follow fork(), so we can check
for leaks in child processes that exit gracefully; but we don't want to
be told about "leaks" in processes that are crashing, because there'd
be no point in cleaning those up anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=666116
This can be used for debugging, or for progress UIs ("Connecting to
example.com..."), or to do low-level tweaking on the connection at
various points in the process.
https://bugzilla.gnome.org/show_bug.cgi?id=665805
Previously it was more or less assumed that GSocketConnections were
always connected, although this was not enforced. Make it explicit
that they don't need to be, and add methods to connect them, and
simplify GSocketClient by using those methods.
https://bugzilla.gnome.org/show_bug.cgi?id=665805
41e5ba86a7 introduced some changes to the
property flags of GAction. These changes were not a reflection of the
actual interface of GAction but were necessary due to GObject being
overly-sensitive to flag changes on property overrides.
Now that the GObject bug is fixed, we can restore the GAction flags to
their correct values.
https://bugzilla.gnome.org/show_bug.cgi?id=666615
It happens that one wants to customize settings for plugins or
shell extensions, that installing schemas in nonstandard locations.
This patch adds the --schemadir option to gsettings, and ensure
that the appropriate schema is found.
https://bugzilla.gnome.org/show_bug.cgi?id=666415
This interfaceifies the extra functions that were on GDBusActionGroup
for dealing with platform data.
The two main benefits of doing this:
- no longer have to do a silly song and dance in GApplication to avoid
calling GDBusActionGroup API from non-dbus-aware code
- the interface can be reused by the action group exporter to avoid
ugly and unbindable hook callbacks
https://bugzilla.gnome.org/show_bug.cgi?id=665737
Now that we're a GActionMap the story about propagating signals from our
(now-constant) internal action group is vastly simplified. If someone
calls g_application_set_action_group() then signals will stop working --
but this function is deprecated and they never worked before, so no big
loss there.
https://bugzilla.gnome.org/show_bug.cgi?id=643736
We provide a mechanism by which a 'platform' (eg: Gtk) can register some
hook functions to be called to collect platform-data at the point of
sending an outgoing action activation request and also to inform the
platform of this data on incoming requests (before and after dispatching
the actual request).
This can be used for forwarding timestamp and startup-notification
information (as is presently done in GApplication) but the before/after
hook could also be used for acquiring/releasing the Gdk lock or other
similar things.
https://bugzilla.gnome.org/show_bug.cgi?id=665737
Various places in the code were assuming that the hash table was always
available. Fix this, and also avoid leaking strings now that the hash
table may be NULL.
Based on a patch by Simon McVittie, bug 666167
g_main_loop_quit() only quits mainloops that are currently running --
not ones that may run in the future. The way the gdbus-threading tests
are written can possibly result in a call to g_main_loop_quit() before
g_main_loop_run() has started.
The mainloops aren't actually used for anything other than signalling
the completion of the threads, so just use g_thread_join() for that.
https://bugzilla.gnome.org/show_bug.cgi?id=666129
When trying to compile glib master on a RHEL 6.2 system, it fails with:
make[4]: Entering directory `/home/teuf/gnome/src/glib/gio'
CC libgio_2_0_la-gnetworkmonitornetlink.lo
In file included from gnetworkmonitornetlink.c:25:
/usr/include/linux/netlink.h:35: error: expected specifier-qualifier-list before 'sa_family_t'
gnetworkmonitornetlink.c: In function 'g_network_monitor_netlink_initable_init':
gnetworkmonitornetlink.c:99: error: 'struct sockaddr_nl' has no member named 'nl_family'
gnetworkmonitornetlink.c💯 error: 'struct sockaddr_nl' has no member named 'nl_pid'
gnetworkmonitornetlink.c💯 error: 'struct sockaddr_nl' has no member named 'nl_pad'
gnetworkmonitornetlink.c:101: error: 'struct sockaddr_nl' has no member named 'nl_groups'
make[4]: *** [libgio_2_0_la-gnetworkmonitornetlink.lo] Error 1
sa_family_t is defined in sys/socket.h, this commit makes sure this header is included before netlink.h
This fixes bgo bug #666001
GDBusConnection recently changed to dispatching its GDestroyNotify calls
from an idle instead of on-the-spot. Under the previous regime, we
would destroy-notify the action group export of a GtkApplicationWindow
at the point it was removed from the application (ie: slightly before
being disposed).
With the destroy notify now deferred to an idle, the window has already
been disposed, so the signal handlers have already been disconnected.
Avoid the problem by dropping our use of signal IDs and just do
g_signal_handlers_disconnect_by_func(), which doesn't complain if there
is no connection.
This was causing the following critical when running bloatpad twice:
GLib-CRITICAL **: g_hash_table_insert_internal: assertion `hash_table != NULL' failed
Clean up the docs for GApplication and related classes.
I'm no longer writing documentation for the structure type of classes
and interfaces. See https://bugzilla.gnome.org/show_bug.cgi?id=665926
for discussin on the correct way forward on this point.
Also: stop putting gtk-doc comments in installed headers.
Have one simple _get() API that returns the group immediately, in an
empty state. The group is initialised on the first attempt to interact
with it.
Leave a secret 'back door' for GApplication to do a blocking
initialisation.
