This should split the code up into logical blocks a bit better, and make
it a bit easier to see what the test is doing at a glance.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This makes the exit conditions for each main loop clearer, and
eliminates use of global variables. It introduces no functional changes.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
If the first part of the test takes less than 3s (which is normal), the
timeout for it is not removed, and could spuriously fire during the
second part of the test, causing a false failure.
Instead of relying on source IDs, just use (and explicitly destroy) a
`GSource` for the timeouts.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
The test thought that calling `g_app_info_get()` was a bit of a hack,
but actually it (or calling another `g_app_info_*()` function) is the
right way to use the `GAppInfoMonitor` API.
See the documentation improvements a couple of commits back for details.
The remaining FIXME higher up in the test should probably be fixed by
getting `g_app_info_monitor_get()` to arm the signal. That requires
changes in `g_app_info_monitor_get()` to call `desktop_file_dir_init()`.
That will have to happen another time.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #799
This is put together through git archaeology:
```
git log gio/tests/appmonitor.c
```
The following commits were too trivial to have meaningful copyright:
- 54047080e9
- 4e7d22e268
- f2c1cfe8c7
- f8f344923e
- 3ce00b29ec
- 3468369625
- e9d9edde82
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1415
It’s been there for 2 years (since commit d81165216d), people have
probably got the message by now.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
It hasn’t been used for years, and isn’t really needed since we changed
to explicitly exporting symbols (using `GLIB_AVAILABLE_IN_*`) rather than
implicitly exporting them unless they were hidden.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This partially reverts ed8e86a7d4.
The change to add the criticals (commit ed8e86a7d4) is correct, but
landed too late in the cycle. Let’s downgrade the criticals to debugs
for now, to stop applications seeing a lot of new criticals in their
output. Those criticals are particularly disruptive for command line
applications and unit tests.
Early in the next cycle, the debugs will be re-upgraded to criticals.
This will give applications a whole additional cycle to fix their
ambiguous use of API.
It turned out that a lot of applications have latent bugs around
calling `g_file_info_get_*()` without checking whether an attribute
is set first, and were hence relying on the ‘unknown’ return value
also being an appropriate default for them.
This was compounded by the fact that several non-local GVFS backends
were not setting `GFileInfo` attributes all the time, which caused the
‘missing attribute’ code path to be hit more frequently. For example,
they would only call `g_file_info_set_is_hidden()` with a true value and
never bother with a false one.
It was further compounded by the fact that, while this change landed for
the 2.75.4 release, there did not seem to be extensive integration
testing of that release, and distributions and downstreams went straight
to 2.76.0. That meant we missed the window between 2.75.4 and 2.76.0 to
change, fix or revert this behaviour. GLib relies on distros and
downstreams doing integration testing of unstable releases. We test with
downstream GNOME as part of gnome-build-meta, but do not have the
resources to do integration testing for everybody.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
See: #2907
See: #2932
See: #2934
See: #2945
See: #2948
This is written in pseudocode C which omits all the callback boilerplate
for the async calls. This should hopefully make the overall structure of
the loop more obvious.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #352
As suggested on #352 by Owen Taylor (commit put together by Philip
Withnall, but in Owen’s name as it’s his wording).
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #352
Before commit ed8e86a7d4, this function would have silently returned a
zero-valued `GTimeVal` if the correct attributes weren’t present.
That partially regressed in commit ed8e86a7d4, which made it return with
a critical warning, but without zeroing the `GTimeVal`. The critical
warning can be ignored by users (it doesn’t abort the process unless
`G_DEBUG=fatal-criticals` is set), but the change in behaviour of
zeroing the `GTimeVal` could cause bugs.
See: #2907
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This fixes bug #624696.
Incorporates a more recent change from 1dc774a653 to drop the
`g_type_init()` call, and reformats the indentation a bit.
Fixes: #322
They just listed built files. Since the move to Meson, these are all
kept in a separate build directory, not the source tree, so don’t need
to be ignored.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Unless `-m thorough` is passed to the tests, reduce the number of
iterations in the random test.
This one test case takes the bulk of the time to run the `queue` test
suite, and is sometimes causing timeouts when running on CI
(particularly under valgrind). Reduce it to a fifth.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This is put together through git archaeology:
```
git log glib/tests/queue.c
git log -- tests/queue-test.c
```
The following commits were too trivial to have meaningful copyright:
- 8f02fac4ad
- d81ac5339f
- 29f2ced8eb
- 1a2c5e155d
- 8a90f5e9f6
- 45dae4b506
- 2aa71ab63b
- 3a74ad128e
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1415
While we can’t check for any events on it, this at least tests that
creating a file monitor works. It should cover the fix from the previous
commit.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: !3241
This should catch regressions in the critical warning fixed in the
previous commit.
The launch has to have several conditions:
- Session bus is running (to avoid the launch happening via the spawn
codepath)
- Use a non-existent D-Bus name (to trigger a launch error)
- Use a launch context (to hit the critical warning code path)
- Not have a startup ID specified in the platform data — this implies
having an empty launch context
- Use an async launch, as that provides an error handling path
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Wrap the logic into a G_ALWAYS_INLINE function, instead of using a
complex statement-expression which is not allowed in braced initializer
lists and expanded into some bad thing when it's used as
`::g_strdup(...)`.
We cannot use `__builtin_constant_p (str)` because GCC documentation
clearly states that it always produces 0 when str is a const char *
argument of an inline function. But `__builtin_constant_p (!str)`,
`__builtin_constant_p (!!str)`, and
`__builtin_constant_p (strlen (str))` functions properly with `-O1` or
above enabled.
Fixes#2936.
It’s possible for the startup ID to be `NULL` if one wasn’t provided in
the platform data passed to `launch_uris_with_dbus()`.
Passing `NULL` to `g_app_launch_context_launch_failed()` causes a
critical warning.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
