In the case that HAVE_DBUS_DAEMON was undefined (as in ostree where glib
is built before D-Bus) this test was failing. Move it inside the
HAVE_DBUS_DAEMON block.
Remove the complications that were introduced in an attempt to make the
gsettings and gschema-compile tests function as installed tests. These
tests are designed (in large part for gsettings and entirely for
gschema-compile) to test the in-tree tools and should not be testing the
system versions.
In the future we may want to move the use of the in-tree tools from the
gsettings testcase into the Makefile and install the resulting files,
allowing this testcase to run against those files, installed.
Perform a substantial cleanup of the build system with respect to
building and installing testcases.
First, Makefile.decl has been renamed glib.mk and substantially
expanded. We intend to add more stuff here in the future, like canned
rules for mkenums, marshallers, resources, etc.
By default, tests are no longer compiled as part of 'make'. They will
be built when 'make check' is run. The old behaviour can be obtained
with --enable-always-build-tests.
--disable-modular-tests is gone (because tests are no longer built by
default). There is no longer any way to cause 'make check' to be a
no-op, but that's not very useful anyway.
A new glibtests.m4 file is introduced. Along with glib.mk, this
provides for consistent handling of --enable-installed-tests and
--enable-always-build-tests (mentioned above).
Port our various test-installing Makefiles to the new framework.
This patch substantially improves the situation in the toplevel tests/
directory. Things are now somewhat under control there. There were
some tests being built that weren't even being run and we run those now.
The long-running GObject performance tests in this directory have been
removed from 'make check' because they take too long.
As an experiment, 'make check' now runs the testcases on win32 builds,
by default. We can't run them under gtester (since it uses a pipe to
communicate with the subprocess) so just toss them in TESTS. Most of
them are passing on win32.
Things are not quite done here, but this patch is already a substantial
improvement. More to come.
This should be the last users that need to be ported.
For some of the oldschool non-gtester-ified tests, we call g_test_init()
from main() because it is necessary in order to use
g_test_build_filename().
Since this feature is so utterly automake-centric, we may as well be
using the same terminology as automake itself (ie: although it's
BUILT_SOURCES, it's DIST_EXTRA, not DISTED).
Also add some comments to the enum explaining that these terms are
really corresponding directly to the automake terms.
https://bugzilla.gnome.org/show_bug.cgi?id=549783
Both g_[file|bytes]_icon_load() leave the `type' out parameter
untouched, while the async methods g_[file|bytes]_icon_load_finish()
always set it to NULL.
For consistency's sake NULLify it in the sync methods too.
https://bugzilla.gnome.org/show_bug.cgi?id=700725
While those strings ("Expecting 1 control message, got %d" and
"Expecting one fd, but got %d\n") have same singular/plural form
in english, it is not necessarily the case in other languages.
https://bugzilla.gnome.org/show_bug.cgi?id=695233
It's a recipe for race conditions and error; on some hardware
architectures one thread isn't guaranteed to see the results
of writes from another thread without a cache flush.
https://bugzilla.gnome.org/show_bug.cgi?id=700855
The test /gdbus/connection/large_message waits for a dbus name to appear.
The dbus name is created by a another process executed in the background.
If for some reason this fails, the test will likely wait forever.
This will avoid this situation by making the test fail if the dbus service
has not appeared after 10 seconds.
https://bugzilla.gnome.org/show_bug.cgi?id=698981
Back in the far-off twentieth century, it was normal on unix
workstations for U+0060 GRAVE ACCENT to be drawn as "‛" and for U+0027
APOSTROPHE to be drawn as "’". This led to the convention of using
them as poor-man's ‛smart quotes’ in ASCII-only text.
However, "'" is now universally drawn as a vertical line, and "`" at a
45-degree angle, making them an `odd couple' when used together.
Unfortunately, there are lots of very old strings in glib, and also
lots of new strings in which people have kept up the old tradition,
perhaps entirely unaware that it used to not look stupid.
Fix this by just using 'dumb quotes' everywhere.
https://bugzilla.gnome.org/show_bug.cgi?id=700746
It tries to run glib-compile-schemas and glib-mkenums, which
we won't have in the runtime tree.
Anyways it's kind of a dumb test since the best test for
compilation tools is...compiling things, which we already
do frequently.
Although none of the in-tree GSocketConnectable types need it, other
types (like SoupAddress) may find it useful to be able to pass a URI
and a default-port to GProxyAddressEnumerator separately (the same way
you can with GNetworkAddress). So add a default-port property.
https://bugzilla.gnome.org/show_bug.cgi?id=698877
The GError should be initialized to NULL, otherwise we'll
"pile up" errors, then try to free an uninitialized pointer.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=699493
Not all systems have /usr/bin/true. Some have it in /bin/true.
Instead of trying to guess a hardcoded path to find it, let
g_app_info_create_from_commandline() internally search PATH
to find the program.
https://bugzilla.gnome.org/show_bug.cgi?id=698655
GUnixSocketAddress has some very strange logic for interpreting its
construct paramters. This logic behaves differently in these two cases:
g_object_new (G_TYPE_UNIX_SOCKET_ADDRESS,
"abstract", FALSE,
"address-type", ...,
NULL);
and
g_object_new (G_TYPE_UNIX_SOCKET_ADDRESS,
"address-type", ...,
NULL);
even though the default value for "abstract" is already FALSE.
Change the way the code works so that it is not sensitive to people
merely setting a property to its default value.
https://bugzilla.gnome.org/show_bug.cgi?id=698686
This function takes a GIcon, serialises it and sets the resulting
GVariant as the "icon" attribute on the menu item. We will need to add
a patch to Gtk to actually consume this icon.
Also add G_MENU_ATTRIBUTE_ICON.
https://bugzilla.gnome.org/show_bug.cgi?id=688820
Add support for serialising a GIcon to a GVariant and deserialising the
result back to a GIcon.
This solves a number of problems suffered by the existing to_string()
API, primarily these:
- not forcing the icon to be a utf8 string means that we can
efficiently encode a PNG (ie: just give the array of bytes)
- there is no need to ensure that proper types are loaded before using
the deserialisation interface. 'Foreign' icon types will probably
emit a serialised format the deserialises to a GBytesIcon.
We additionally clearly document what is required for being a consumer
or implementation of #GIcon.
Further patches will be required to GdkPixbuf and GVfsIcon to bring
their implementations in line with the new rules (essentially: introduce
implementations of the new serialize() API).
https://bugzilla.gnome.org/show_bug.cgi?id=688820
GBytesIcon is an icon that has a GBytes inside of it where the GBytes
contains some sort of encoded image in a widely-recognised file format.
Ideally this will be a PNG.
It implements GLoadableIcon, so GTK will already understand how to use
it, but we will add another patch there to make things more efficient.
https://bugzilla.gnome.org/show_bug.cgi?id=688820
Split out the 'simple string format' cases of URIs, file paths and
themed icons to a separate function.
This function will be shared by g_icon_deserialize().
https://bugzilla.gnome.org/show_bug.cgi?id=688820
In the *_async_thread() functions, call the corresponding synchronous
function instead of calling the interface vfunc, which can be NULL.
In some cases the check for the vfunc == NULL was done, but to be
consistent it is better to always call the synchronous version (and the
code is simpler).
https://bugzilla.gnome.org/show_bug.cgi?id=548353
This feature is intended for clients that want to signal a desktop shell
their busy state, for instance because a long-running operation is
pending.
The API works in a similar way to g_application_hold and
g_application_release: applications can call g_application_mark_busy()
to increase a counter that will keep the application marked as busy
until the counter reaches zero again.
The busy state is exported read-only on the org.gtk.Application interface
for clients to use.
https://bugzilla.gnome.org/show_bug.cgi?id=672018
It is possible that the upstream servers return something, but
we then filter all results because they are of the wrong type.
In that case the API and subsequent GTask calls expect a GError
to be set.
https://bugzilla.gnome.org/show_bug.cgi?id=696857
to avoid warnings when built with -Wredundant-decls:
sessionmanager-presence-generated.c:316:1: warning: redundant redeclaration of ‘session_manager_presence_default_init’ [-Wredundant-decls]
sessionmanager-presence-generated.c:281:1: note: previous definition of ‘session_manager_presence_default_init’ was here
sessionmanager-presence-generated.c:1273:1: warning: redundant redeclaration of ‘object_default_init’ [-Wredundant-decls]
sessionmanager-presence-generated.c:1259:1: note: previous definition of ‘object_default_init’ was here
https://bugzilla.gnome.org/show_bug.cgi?id=696108
Expand and formalise the syntax for detailed action names, adding a
well-documented (and tested) public parser API for them.
Port the only GLib-based user of detailed action names to the new API:
g_menu_item_set_detailed_action(). The users in Gtk+ will also be
ported soon.
https://bugzilla.gnome.org/show_bug.cgi?id=688954
We need to close the stream *before* applying the file modes, because
g_file_replace() allocates a temporary file. At the moment we're
applying the modes to the extant file, then immediately rename()ing
over it with the default perms.
This regressed with commit 166766a89f.
The real fix here is to have g_file_create_with_info() so that we can
atomically create a file with the permissions we want.
https://bugzilla.gnome.org/show_bug.cgi?id=696014
_g_dbus_method_invocation_new is said to allow method_info == NULL,
but will crash inside g_dbus_method_info_ref when the method_info
really is NULL, because g_dbus_method_info_ref does not allow NULL as
parameter. Fixed by checking for NULL in _g_dbus_method_invocation_new
itself.
The leak itself happens because _g_dbus_method_invocation_new stores a
new reference to the method_info without also unreferencing it. Fixed
by adding the missing unref, protected by an if because the pointer
may be NULL.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=695376
We were using PATH_MAX to size a static array for reading lines from
the .hidden file. Some platforms (Hurd) don't declare a PATH_MAX.
Switch to using g_file_get_contents() and g_str_split('\n') instead.
Also take the time to clean up a bit with a switch to using a 'set mode'
GHashTable (since this code was originally written before we had those).
This patch is largely based on a patch from Emilio Pozuelo Monfort (who
also reported the bug).
https://bugzilla.gnome.org/show_bug.cgi?id=695147
Commit f641699 (for bug 675333) introduced a check whether the Exec= program in
a .desktop actually exists. This broke the /appinfo/mime/* test cases which use
executable names like "my_app".
Use real ones instead (like "echo" and "sleep"), and add a new
/appinfo/mime/ignore-nonexisting test case which verifies that
g_desktop_app_info_new() indeed ignores nonexisting executables.
https://bugzilla.gnome.org/show_bug.cgi?id=695191
