This is possible now that we have better support for object path
arrays, see
http://git.gnome.org/browse/glib/commit/?id=19878998bc386db78614f1c92ff8524a81479c7b
Note that this breaks the ABI of generated code but since
gdbus-codegen(1) has never yet been in a stable GLib release, this is
fine.
Signed-off-by: David Zeuthen <davidz@redhat.com>
In an attempt to avoid some potential future abuses of the GParamSpec
API, qualify the 'name' field of the structure as 'const' and add a
comment noting that it is an interned string.
This is a theoretical API break, but it will only ever result in
warnings -- and even then, only if you were already doing something
questionable.
Clean up some of the warnings that were caused internally in gparam.c
from these changes.
David requested that I change the order of the flags.
Also, assign numerical values to the flags in the usual way. This
wasn't a bug yet, but only by chance.
The Asturian, French, Norwegian Nynorsk and Spanish translations
incorrectly translated "MB" and friends to "MiB" (french: "Mio"), etc.
This was in response to the incorrect use of "MB" in the (now
deprecated) g_format_size_for_display() function.
These strings are now used (correctly) in g_format_size(), so I have
updated the translations accordingly.
Additionally, the Norwegian Nynorsk translation was incorrectly
translating several larger units to "KiB", so that has been corrected as
well.
This commit changes GLib size units policy. We now prefer SI units and
allow for use of proper IEC units where desired.
g_format_size_for_display() which incorrectly mixed IEC units with SI
suffixes is left unmodified, but has been deprecated.
g_format_size() has been introduced which uses SI units and suffixes.
g_format_size_full() has also been added which takes a flags argument to
allow for use of IEC units (with correct suffixes). It also allows for
a "long format" output which includes the total number of bytes. For
example: "238.5 MB (238,472,938 bytes)".
Rename the size constants from KILOBYTE to KIBIBYTE (etc.) since that's
what they really are.
This is a strictly internal change with no externally-visible effect in
terms of API or functionality.
The choice between g_variant_iter_next() and g_variant_iter_loop() is a
bit confusing for some people. Add a note to the documentation of
g_variant_iter_loop() to clarify that it should be avoided except in a
few specific cases.
Add G_VARIANT_TYPE_OBJECT_PATH_ARRAY along with accessor functions
g_variant_new_objv, g_variant_get_objv and g_variant_dup_objv. Also add
support for '^ao' and '^a&o' format strings for g_variant_new() and
g_variant_get().
https://bugzilla.gnome.org/show_bug.cgi?id=654955
If we are going to fail an assert, wait for a bit longer before doing so
(up to 5 seconds, if needed).
This is a long-standing Debian patch to fix build failures on really
slow machines.
- move choice of statfs vs statvfs from gio/glocalfile.c to configure.ac
- if statvfs is the choice, then don't check number of arguments to statfs()
- use choice in gio/gunixmounts.c as well
https://bugzilla.gnome.org/show_bug.cgi?id=617949
Previously, when a binary did not run a single test - for whatever
reason, from the binary not existing to the binary not using the gtester
framework - no failures were recorded. Now we record a non-successful
run of a binary that did not start any tests as a failure, too.
Note that this does not change the behavior of any binaries that exit
successfully or that report the start of any gtester test.
Previously, gtester used the testcase_fail_count as the number of tests
that failed in the latest run testcase, but then use that as the return
value of main().
Now we count the failed testcases of the whole run.
