The documentation previously implicitly said in a few places that
interfaces are classed, but reading through the implementation of
`GType`, I don’t think they are. If they were, the registration of the
fundamental `G_TYPE_INTERFACE` in `gobject_init()` would specify
`G_TYPE_FLAG_CLASSED`. It only specifies `G_TYPE_FLAG_DERIVABLE`.
I think this makes sense, because you can’t subclass an interface.
Subclassing is a key property of being classed.
Tweak the `GType` tutorial to remove that implicit statement, and expand
the documentation for `G_TYPE_IS_CLASSED`.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #252
‘returns TRUE on success’ is misleading for a lot of these macros, as
they are checking whether a type has a certain property. Such a check
could be successful but return `FALSE`, by the normal meaning of the
word ‘success’.
Instead, reword the docs to spell out when `TRUE` will be returned.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
See issue GNOME/glib#2861. Even though (hopefully!) few people are
actually running kernels this old, some build frameworks use very old
kernel headers to try to maximize the portability of their binary
artifacts.
Correct the info on G_PLATFORM_WIN32, now that we only define it when
GLib is built for native Windows, not Cygwin. Make it clear that it
should not be used to check for conditional compilation for Cygwin
builds of GLib.
clang++ says it supports _Static_assert but then will
complain that it's a C11 extension and that you should not use
it in C++ code (which imho is fair enough)
So try to detect a C++ compiler first and then the C compiler,
similarly to what is done for the G_NORETURN case
Both `GPollableInputStream` and `GPollableOutputStream` are dynamic
interfaces, in that their implementation on a class may only be
functional if certain prerequisites are met at runtime. For example,
a `GConverterInputStream` is only pollable if its base stream is
pollable, and that’s determined at runtime rather than compile time.
As such, both interfaces have a `can_poll()` method. If that method
returns `FALSE`, the behaviour of all other methods on the interface is
undefined.
That was mentioned in the documentation for `can_poll()`, but not any of
the other documentation for the interfaces, which made it a bit hard to
find.
Mention it more widely.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2952
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:
- 54047080e963b2d6c3f966340dcd9d788b73ac9c
- 4e7d22e268a4e06beb1c09585a48288c31004da5
- f2c1cfe8c770f73367a021044bcdda550348714c
- f8f344923eba57ca13d82e53f3e7b82633179f43
- 3ce00b29ec0bb240412506affb5c65bdb18c7ad3
- 346836962521cce76f3cbd53259a985d3bef6a2a
- e9d9edde824df1229bc5539610b98c98013e93aa
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
