If `-Ddocumentation=true` is specified without
`-Dintrospection=enabled`, warn the user. They might expect the
documentation to be built, but it won’t.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
It doesn’t list all mounts, only the ones you’d expect to see in a file
chooser sidebar.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3555
systemd 257 will now set `DEBUG_INVOCATION=1` in the execution context
of services which need to be debugged — for example if they’ve failed
and been restarted (and `RestartMode=debug`).
If we handle `DEBUG_INVOCATION=1` as being equivalent to
`G_MESSAGES_DEBUG=all`, then any processes using GLib’s default log
writer function (or `g_log_writer_default_would_drop()`) automatically
gains support for this feature.
See https://mastodon.social/@pid_eins/113548825942383777
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
I wish people would stop moving their documentation around without
adding redirects. This is not how the internet is supposed to work.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
As per https://gitlab.gnome.org/GNOME/glib/-/issues/3421#note_2206315:
It seems like there’s agreement that glib_debug should be enabled for
developers and disabled for distros; and it also seems like there’s no
reliable way to figure this out magically (because not everyone ties
things to `-Dbuildtype=*`). So, we’re left with forcing some group of
people to manually set the value of `glib_debug`. There are more
developers/contributors than there are distros, and distros are more
likely to notice an accidentally-slow GLib package than developers are
likely to notice an accidentally-not-asserting-hard-enough local build,
so let’s say:
The default should be `-Dglib_debug=enabled`, and distros should probably
all override that to `-Dglib_debug=disabled`.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3421
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>
These rules are not new, they’ve been around for a long time and are
needed to allow introspection machinery to be able to work reliably and
deterministically.
Unfortunately, they have not been documented canonically in one place
before.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
* Create a dark-mode variant of each traversal diagram, with the
traversal path colorized `--primary` blue, instead of the original
black.
* Apply the same colorizations to the light-mode diagrams, but
using the light-theme `--primary` blue.
* Add SPDX license/copyright comments to all eight SVG files.
* Add new files to documentation configs in `glib.toml.in`.
* Update documentation comment in `gnode.c` to embed both color
variants via picture tags, instead of markdown image embeds.
* Add alt text to all four images.
* Add additional blank lines to documentation comment, so that
a. First item in bulleted list does not get folded into
preceding intro paragraph
b. Intro paragraph and diagrams are not part of first paragraph
in documentation. (This also gets them out of the top-level
table-of-contents/index list, where they previously appeared
in full.)
* (Accidental change I didn't realize I was making): Convert line
endings in breadth-first diagram from CRLF to LF.
- Add licensing tags
- Tweak spacing, colors, line thicknesses
- Create light-mode version
- Use `<picture>` tag to include appropriate version for each media
color scheme.
Recreate the `menu-model.png` diagram in SVG, with box outlines and
connectors recolored from black to white. This will allow the diagram
to show up better in the dark documentation theme.
We have required C99 for a while; in the meantime, most C toolchains
have moved on to C11 or later as the default C standard.
We still allow for C99 toolchains, but in the future we are going to
require a C11 toolchain to build and use GLib.
glib-compile-schemas considers XDG_DATA_HOME in addition to
XDG_DATA_DIRS since GLib 2.53.2, but this is not mentioned in its manual
and might bring confusion to readers.
Commit d0e03f09 introduced GTYPE_TO_POINTER/GPOINTER_TO_TYPE, on which
work started before the move of conversion macros to Markdown. It did
get merged after that move, but the macros never made it into the docs.
Let's do so now.
There is no need to use double backticks. Also, insert extra newlines
between header and item, which paragraphs the item [1, 2], increading
readability by giving a little more "breathing" room between items. This
is also done in `macros.md`. Also, indentation of the definition block
should technically be 4 if extra paragraphs are needed, but it's better
to use 4 indentation always to prevent future problems after edits.
[1] https://python-markdown.github.io/extensions/definition_lists/
[2] https://michelf.ca/projects/php-markdown/extra/#def-list
- Do not refer to people’s expectation, they can wildly differ.
- Do not link to `strcompress`, that confusingly does not support `\a`. Link Wikipedia instead.
- Reiterate the C escape sequences from string section, they are not that many.
- Mention escaping newline and other characters (also copied from string section).
- Mention Unicode escapes not being supported to contrast with strings.
Fedora 37 is out of support so, as per our policy, update the CI image
to the oldest still-supported release, which is 39.
Update the mingw CI image too, as it’s built on top of the Fedora one.
Update the supported platforms documentation (and fix the Debian version
listed there to match what’s currently in CI, which is up to date).
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
548ec9f186 accidentally moved the GVariant
spec to the toplevel /usr/share/doc directory, which is surely not
right. Let's move it back into the glib-2.0 subdirectory.
It's debatable whether this is the best place to install the GVariant
specification, since it's not part of the gi-docgen docs, but surely
it's much better than not putting it in any subdirectory.
Fixes#3351
