This was one of the code paths not currently covered by unit tests, so
let’s add a test for it.
This tests what happens when a structurally valid GResource file, but
with a corrupt entry for a compressed file, is loaded.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3465
This is slightly more involved than the previous couple of commits, as
`g_resource_lookup_data()` can return two errors: one if the resource is
not found, and another if decompression fails.
We want to avoid allocating the `G_RESOURCE_ERROR_NOT_FOUND` error, as
`g_resources_lookup_data()` will be looping through multiple
`GResource`s trying to find the given path, and all but one of them will
return `G_RESOURCE_ERROR_NOT_FOUND`. For a large application, this can
amount to a lot of `GError`s allocated and then immediately freed on
startup.
Use the split from the previous commit to replace the call to
`g_resource_lookup_data()` with its two constituent parts. We can then
handle errors from them separately, ignoring the `NOT_FOUND` error from
`do_lookup()`, while paying attention to any errors from
`resource_to_bytes()`.
This should result in no functional difference to
`g_resources_lookup_data()`, but fewer allocations overall.
Spotted by Christian Hergert.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3465
It’s now a call to `do_lookup()` followed by a call to
`resource_to_bytes()`. This makes no functional changes, but will be
useful in the following commit.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3465
As with the previous commit:
The error here can only ever be `G_RESOURCE_ERROR_NOT_FOUND`, which
`g_resources_get_info()` immediately frees. So let’s avoid allocating
the error in the first place.
Spotted by Christian Hergert.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3465
The error here can only ever be `G_RESOURCE_ERROR_NOT_FOUND`, which
`g_resources_open_stream()` immediately frees. So let’s avoid allocating
the error in the first place.
Spotted by Christian Hergert.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3465
This makes it a bit easier to make sure all the translatable strings are
kept in sync. It introduces no functional changes.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3465
The test in `unix-mounts` to see whether `g_unix_mounts_get_from_file()`
can parse an example file was working fine when GLib is built with
libmount, but not when built without it (and hence typically using
`getmntent()`).
This is because libmount supports mountinfo files (like
`/proc/self/mountinfo`), but `getmntent()` only supports mount files
(like `/proc/mounts`). The test was written only with the former.
So, change the test to use mount files when GLib is built without
libmount support.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3456
This kind of deeply nested menu is definitely no longer good UI practice
for most apps (deeply nested menus make things hard to find, and require
good mouse control to navigate). However, it does serve as a good
demonstration of the concepts in `GMenuModel`, so keep it, with a
sentence to acknowledge that it’s not a good UI.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3451
These tests are expected to cause a thread to deadlock. That seems to be
fine with glibc on Linux, but the glibc version on FreeBSD can detect
the deadlock, and aborts the whole test process with:
```
GLib (gthread-posix.c): Unexpected error from C library during 'pthread_mutex_lock': Resource deadlock avoided. Aborting.
```
This is fair enough.
To avoid this causing the test suite to fail, run those two tests in
subprocesses. This also means we’re not carrying a deadlocked thread
around for the rest of the test suite.
Improves on commit 62192925b6.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Provide examples of what they all represent, and expand on the
descriptions of them in a few places.
Move references to their equivalents from `GnomeVFS` to lower down in
the documentation, since `GnomeVFS` has been deprecated for many years
now, and is unlikely to be pertinent to most readers.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
When listing schemas from a specified directory, explicitly
create the GSettings object from the schema, don't allow g_settings_new
to do the usual lookup. That lookup fails if no other schemas are
installed in the default directories.
Fixes#3429.
This can never have been tested, it was returning `GUnixMountEntry`
structs from functions which are typed to return `GUnixMountPoint`s.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
While GLib doesn’t parse these files, it does provide API to access the
fields from them, and does implement some logic based on options fields
in them. It would be nice to be able to test that, and get coverage of
the methods for `GUnixMountPoint` and `GUnixMountEntry`.
We don’t expect users to start querying the fstab or mtab by explicitly
loading data from those file paths. These functions are mainly intended
to prove a controllable entry point into the `gunixmounts.c` code for
unit testing.
It means we can provide a file with controllable contents in order to
test the mount entry/point code on.
See: https://gitlab.gnome.org/GNOME/glib/-/merge_requests/4155
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
You may not always know which schemes are available.
The library should not bail out, but only show
an informal message. It's the responsibility of
the application to deal with invalid URI schemes.
The test brings a Finder window to the front. It's not ideal,
but I have no better idea at the moment. It would be cool if we
can make the test case register itself as handler for a particular
uri scheme, but I have no idea how to do that.
I answered a question on irc about withdrawing notifications, and
when I handed out a link to the GApplication docs, I noticed we
don't have this function name linkified. Fix that.
On Wayland the activation token returned by
`g_app_launch_context_get_startup_notify_id()` doesn't depend on the
`GAppInfo`. The token is only used to hand over focus to the
application that is launched. In some cases it's not even possible to know
what application will actually be used to open the files. For example
when using portals within a sandbox. Therefore, allow providing no
`GAppInfo`.
This also makes clear in the docs that the `files` argument can be `NULL`.
We want to add the support for the activation token, to get it we use
`g_app_launch_context_get_startup_notify_id` which takes a list of
files, so that we don't have to create a GFile twice simply change the
signature of the functions. Fortunately this isn't a public API.
This file doesn’t contain any real implementation, it just call the
`impl` functions from the platform-specific files
`gcontenttype-{fdo,osx,win32}.[cm]`.
It serves as a location for the doc comments, introspection annotations
and API preconditions, and will be built on every platform. In
particular, this means that we get consistent GIR output for the
`g_content_type_*()` APIs regardless of whether GLib was built on Linux or
Windows or macOS.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3399
This reflects its status as actually platform-dependent: it’s only built
on systems using the freedesktop.org content type system.
It makes the file naming match up with other platform-specific
implementations, such as `gcontenttype-win32.c` and
`gcontenttype-osx.m`.
A subsequent commit will introduce a platform-independent high level API
wrapper so that the introspection annotations from this file can be
reused between platforms.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3399
Previously, some of the doc comments for platform-independent APIs were
in `gdesktopappinfo.c`, which is only built on Unix systems. This meant
the introspection annotations for those APIs were not used on non-Unix
systems, which caused platform differences in `Gio-2.0.gir`.
So, move those doc comments to `gappinfo.c` and put them next to some
new platform-independent wrapper functions which provide a consistent
entry point and location for the API preconditions.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3399
