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.
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
The source language of GLib is technically en-US, so we should
consistently use en-US spellings.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3269
The `gi-docgen` tool is not designed to be used like that. In
particular, when nesting documentation directories, the generated
`*.devhelp2` files (needed by Devhelp to show the documentation) are
nested one directory level too deep for Devhelp to find them, and hence
are useless, and the documentation doesn’t show up in this common
documentation viewer.
So, change the installed documentation directory hierarchy:
* `${PREFIX}/share/doc/glib-2.0/gio` → `${PREFIX}/share/doc/gio-2.0`
* `${PREFIX}/share/doc/glib-2.0/glib-unix` →
`${PREFIX}/share/doc/glib-unix-2.0`
* `${PREFIX}/share/doc/glib-2.0/gobject` →
`${PREFIX}/share/doc/gobject-2.0`
* etc.
* `${PREFIX}/share/doc/glib-2.0/glib` → `${PREFIX}/share/doc/glib-2.0`
This is going to seem like pointless churn (the contents of the
documentation have not changed), and packagers may mourn the split of
content in `/usr/share/doc` from `/usr/share/doc/${package_name}` to
`/usr/share/doc/${pkg_config_id}` instead, but that seems to be the best
approach to fix this issue in GLib. gi-docgen’s behaviour does feel
fairly consistent and correct with the rest of how it works (single
output directory).
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3287
This is nowhere near a complete check-through and gi-docgenification of
the signals docs, just a few bits I was looking at anyway.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3250
We install gvariant-specification-1.0.html to `docs_dir` but that shouldn't require `enable_gir`.
Fixes: docs/reference/glib/meson.build:26:16: ERROR: Unknown variable "docs_dir"
Part-of: <https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3955>
gi-compile-repository --module and gi-decompile-typelib --shlib are
intentionally undocumented here: they will be removed in !3926.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This is a behaviour change from g-ir-generate, which treats it as
least-important-first (the last directory on the command-line is
searched first).
gi-compile-repository --includedir and gcc -I are most-important-first
(the first directory on the command-line is searched first) so it seems
like it makes most sense to be consistent with that.
Signed-off-by: Simon McVittie <smcv@collabora.com>
So now introspection users will have to call `GLibUnix.open_pipe()`
rather than `GLibUnix.unix_open_pipe()` — or
`GLibWin32.check_windows_version()` rather than
`GLibWin32.win32_check_windows_version()`.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3037
This should clarify things a little for users of language bindings, who
don’t directly use `.pc` files.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
This creates `GioUnix`, `GioWin32`, `GLibUnix` and `GLibWin32`. These
bodies of documentation are in addition to the main, platform agnostic,
documentation for both libraries.
This commit necessarily includes various mechanical changes to update
the repository namespace used in various existing documentation links to
platform specific APIs.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3037
Seems no point in keeping them separate. It doesn’t seem to matter if
they contain entries which are unused for a particular docs build.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
`--version` is conventionally used to find the version of the program
itself. While that’s not currently implemented in
`gi-inspect-repository`, let’s not box ourselves into a corner.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Eventually, we want to move to using `GType` directly for everything,
since `GIBaseInfo` and its subclasses are all using `GTypeInstance`.
However, that requires quite a lot of changes and we’re about to hit the
API freeze.
So do the smallest set of changes possible to remove `GIInfoType` and
related functions from the public API, which gives us freedom to make
more changes later without breaking API.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
