gtk-doc issueshttps://gitlab.gnome.org/GNOME/gtk-doc/-/issues2018-05-22T13:13:57Zhttps://gitlab.gnome.org/GNOME/gtk-doc/-/issues/43Out of tree builds cause make install to re-gen gtk-doc2018-05-22T13:13:57ZBugzillaOut of tree builds cause make install to re-gen gtk-doc## Submitted by Ross Burton
**[Link to original bug (#794571)](https://bugzilla.gnome.org/show_bug.cgi?id=794571)**
## Description
If glib is configured to do an out-of-tree build then this happens:
1) configure runs and generates ...## Submitted by Ross Burton
**[Link to original bug (#794571)](https://bugzilla.gnome.org/show_bug.cgi?id=794571)**
## Description
If glib is configured to do an out-of-tree build then this happens:
1) configure runs and generates build/docs/reference/glib/version.xml
2) make all runs, the gtk-doc.make setup-build target copies all content files from $srcdir to $builddir. This replaces the generated version.xml with the original in the tarball. It then proceeds to generate gtk-doc.
3) make install runs, make notices that version.xml is older than config.status, so re-runs config.status to regenerate version.xml and so regenerates the gtk-doc again before installing it.
My hacky patch is:
--- a/gtk-doc.make
+++ b/gtk-doc.make
@@ -113,3 +113,3 @@ setup-build.stamp:
test -f $(abs_srcdir)/$$file && \
- cp -pf $(abs_srcdir)/$$file $(abs_builddir)/$$file || true; \
+ cp -pn $(abs_srcdir)/$$file $(abs_builddir)/$$file || true; \
done; \
(only copy files which don't exist already)
But why does gtk-doc need to copy the content at all?
Version: 1.27https://gitlab.gnome.org/GNOME/gtk-doc/-/issues/42Documentation of plain structs broken again2018-05-22T13:13:44ZBugzillaDocumentation of plain structs broken again## Submitted by Yeti
**[Link to original bug (#794299)](https://bugzilla.gnome.org/show_bug.cgi?id=794299)**
## Description
As long as one adds any kind of GObject machinery to C structs, their members become impossible to document....## Submitted by Yeti
**[Link to original bug (#794299)](https://bugzilla.gnome.org/show_bug.cgi?id=794299)**
## Description
As long as one adds any kind of GObject machinery to C structs, their members become impossible to document. This includes boxing them, making them class structs, etc.
The members are documented for a reason, stop hiding the documentation!
This has been a problem several times in the past. I had to insert scripts into the build process that fight gtk-doc and save the structs from SUBSECTION Standard, but 1.27 is more resistant.
It may be somewhat controversial that I have classes (and occasionally objects) with public members and want to document them. Even though it should not be controversial at all -- choose your favourite level of encapsulation, and let others choose theirs.
And what definitely should not be controversial is that the possibility to document trivial structs such as
typedef struct {
gint datano;
gint id;
} GwyAppDataId;
Once a get-type function
#define GWY_TYPE_APP_DATA_ID (gwy_app_data_id_get_type())
GType gwy_app_data_id_get_type (void) G_GNUC_CONST;
is added for it (because the struct it is also useful to box) -- bam!
INFO:root:Found gobject type 'GWY_APP_DATA_ID' from get_type function
INFO:root: Hide instance docs for gwyappdataid
INFO:root: Hide class docs for gwyappdataid
INFO:root: Hide iface docs for gwyappdataid
INFO:root: Hide iface docs for gwyappdataid
and the documentation disappears. And there is no way to get it back.
Version: 1.27https://gitlab.gnome.org/GNOME/gtk-doc/-/issues/40Devhelp index file: differentiate signals or properties with the same name by...2021-07-09T16:26:36ZBugzillaDevhelp index file: differentiate signals or properties with the same name by adding the class name## Submitted by Sébastien Wilmet `@swilmet`
**[Link to original bug (#792778)](https://bugzilla.gnome.org/show_bug.cgi?id=792778)**
## Description
See attachment 351699, a screenshot of Devhelp with the search results for "populate-...## Submitted by Sébastien Wilmet `@swilmet`
**[Link to original bug (#792778)](https://bugzilla.gnome.org/show_bug.cgi?id=792778)**
## Description
See attachment 351699, a screenshot of Devhelp with the search results for "populate-popup" (with the GTK+ book enabled). There are lots of duplicates because different classes have the same signal name.
It would be nice to know the class that the signal belongs to.
In gtk3.devhelp2 the keyword currently looks like:
> <keyword type="signal" name="The “populate-popup” signal"
> link="GtkLabel.html#GtkLabel-populate-popup"/>
A possible replacement:
> name="The GtkLabel::populate-popup signal"
Same problem with properties. Example of a better name:
> name="The GtkApplication:active-window property"
It is better to solve this problem in gtk-doc, not Devhelp, to fix the problem at the source.https://gitlab.gnome.org/GNOME/gtk-doc/-/issues/39gint and guint misrepresented as functions2018-11-30T11:55:34ZBugzillagint and guint misrepresented as functions## Submitted by Jan Alexander Steffens `@heftig`
**[Link to original bug (#789087)](https://bugzilla.gnome.org/show_bug.cgi?id=789087)**
## Description
The "Basic Types" documentation page lists the `gint` and `guint` symbols as fun...## Submitted by Jan Alexander Steffens `@heftig`
**[Link to original bug (#789087)](https://bugzilla.gnome.org/show_bug.cgi?id=789087)**
## Description
The "Basic Types" documentation page lists the `gint` and `guint` symbols as functions instead of types.
This seems to have been introduced somewhere between 2.46.2 and 2.48.2 (or perhaps in the gtk-doc versions used), as seen in the hosted docs:
https://developer.gnome.org/glib/2.46/glib-Basic-Types.html#gint
https://developer.gnome.org/glib/2.48/glib-Basic-Types.html#gint
Version: 1.26https://gitlab.gnome.org/GNOME/gtk-doc/-/issues/38Poor W32-meson compatibility2018-05-22T13:12:04ZBugzillaPoor W32-meson compatibility## Submitted by LRN `@ruslanizhb`
**[Link to original bug (#788911)](https://bugzilla.gnome.org/show_bug.cgi?id=788911)**
## Description
Since 1.26, gtk-doc got a new, shiny Python rewrite, and i hoped that this would fix meson inte...## Submitted by LRN `@ruslanizhb`
**[Link to original bug (#788911)](https://bugzilla.gnome.org/show_bug.cgi?id=788911)**
## Description
Since 1.26, gtk-doc got a new, shiny Python rewrite, and i hoped that this would fix meson integration[1] when running on Windows.
I was wrong.
The crux of the matter is the fact that gtk-doc remains very *nix-y due to the tools that it uses (xsltproc & docbook, vim). For example, it must ensure that XML_CATALOG_FILES is a :-separated list of *nix paths, not a ;-separated list of W32 paths, otherwise xsltproc[2] will fail to find the stylesheets (or whatever it is that it looks for in the filesystem). Vim also requires some state that doesn't seem[3] to survive the MSYS(bash)->W32 (python-meson+python-gtk-doc)->MSYS(vim) trip, and fails to do the highlighting that it is supposed to do (so far i was unable to figure out exactly which environmental variable breaks it).
This means that the W32/MSYS separation line should be drawn between meson and gtk-doc (whereas previously it didn't exist - gtk-doc was invoked by autotools & make, both of which were on MSYS side of things already, same as gtk-doc itself).
That might be doable (though i doubt that meson devs will happily accept the necessary patches). Obviously, by remaining *nix-y gtk-doc will [likely] remain unusable for MSVC users (not that i care, you understand).
What is the official Windows compatibility policy for gtk-doc? And for Gnome in general, as far as documentation goes.
[1] meson integration matters because gtk4 generation of the stack already lost autotools support, and i fear that gtk3 generation of the stack is next in line
[2] MSYS-xsltproc is used in favour of MinGW-xsltproc because otherwise various *nix-y paths widely hard-coded into stylesheets don't work
[3] Note that my MSYS2 environment is slightly unusual (also, quite old), so it's possible that official MSYS2 works around this somehowhttps://gitlab.gnome.org/GNOME/gtk-doc/-/issues/37gtkdoc-scan parse error on trivial whitespace change2022-08-23T18:15:56ZBugzillagtkdoc-scan parse error on trivial whitespace change## Submitted by Andreas Metzler
**[Link to original bug (#788379)](https://bugzilla.gnome.org/show_bug.cgi?id=788379)**
## Description
Hello,
gtkdoc-scan fails when struct definitions are indented with whitespace:
```
(sid)ametzle...## Submitted by Andreas Metzler
**[Link to original bug (#788379)](https://bugzilla.gnome.org/show_bug.cgi?id=788379)**
## Description
Hello,
gtkdoc-scan fails when struct definitions are indented with whitespace:
```
(sid)ametzler@argenau:/tmp$ rm -f foo-decl-list.txt ; echo testin/foo.h: ; cat testin/foo.h ; gtkdoc-scan --module=foo --source-dir=testin ; echo foo-decl-list.txt: ; cat foo-decl-list.txt
```
- `testin/foo.h`
```c
#define NUMBERX 42
struct foo_st
{
const char *name; /* Name */
};
typedef struct foo_st foo;
#define NUMBERY 23
```
- `foo-decl-list.txt`
```
<SECTION>
<FILE>foo</FILE>
NUMBERX
</SECTION>
```
```
(sid)ametzler@argenau:/tmp$ rm -f foo-decl-list.txt ; echo testin/foo.h: ; cat testin/foo.h ; gtkdoc-scan --module=foo --source-dir=testin ; echo foo-decl-list.txt: ; cat foo-decl-list.txt
```
- `testin/foo.h`
```c
#define NUMBERX 42
struct foo_st
{
const char *name; /* Name */
};
typedef struct foo_st foo;
#define NUMBERY 23
```
- `foo-decl-list.txt`
```
<SECTION>
<FILE>foo</FILE>
NUMBERX
foo_st
foo
NUMBERY
</SECTION>
```
This applies to both 1.25 and 1.26.
cu Andreas
Version: 1.26https://gitlab.gnome.org/GNOME/gtk-doc/-/issues/36api-index for specific versions not generated in HTML2023-03-04T20:36:28ZBugzillaapi-index for specific versions not generated in HTML**Update** / TL;DR: It's a bug in the docbook stylesheet, see: \
https://sourceforge.net/p/docbook/bugs/1401/
## Submitted by Sébastien Wilmet `@swilmet`
**[Link to original bug (#785139)](https://bugzilla.gnome.org/show_bug.cgi?id=7...**Update** / TL;DR: It's a bug in the docbook stylesheet, see: \
https://sourceforge.net/p/docbook/bugs/1401/
## Submitted by Sébastien Wilmet `@swilmet`
**[Link to original bug (#785139)](https://bugzilla.gnome.org/show_bug.cgi?id=785139)**
## Description
I've found another regression after the Python port of gtk-doc (up-to-date from git master, at commit 8f451a6).
For example in gspell after running `make`:
$ cd docs/reference/
$ ls -1 xml/api-index-*
xml/api-index-1.2.xml
xml/api-index-1.4.xml
xml/api-index-1.6.xml
xml/api-index-deprecated.xml
xml/api-index-full.xml
$ ls -1 html/api-index-*
html/api-index-full.html
(There are no deprecated symbols in gspell so I think it's normal that api-index-deprecated.html is not generated).
api-index-1.2.html etc are missing.
See:
https://git.gnome.org/browse/gspell/tree/docs/reference/gspell-docs.xml.in?h=1.5.3#n63
I have the same problem with other modules.
Version: 1.25https://gitlab.gnome.org/GNOME/gtk-doc/-/issues/35ability to customize headers and footers in html output2018-05-22T19:40:20ZBugzillaability to customize headers and footers in html output## Submitted by John Cupitt
**[Link to original bug (#781291)](https://bugzilla.gnome.org/show_bug.cgi?id=781291)**
## Description
I'm using gtk-doc for my project and I needed to be able to change the headers and footers in the for...## Submitted by John Cupitt
**[Link to original bug (#781291)](https://bugzilla.gnome.org/show_bug.cgi?id=781291)**
## Description
I'm using gtk-doc for my project and I needed to be able to change the headers and footers in the formatted output to make nice online docs.
I understand gtk-doc is currently being redesigned to include this feature, so maybe my experience is a possible sample use-case. This has been discussed on the gtk-devel mail list here:
https://mail.gnome.org/archives/gtk-devel-list/2017-April/msg00002.html
Summary:
I wanted to be able to put google analytics into the footer of each page, so I can see which doc pages people find most useful, and I wanted to swap the front matter in the page for something that would style the output to match the rest of my micro-site.
I took one of the standard gh-pages jekyll templates:
https://github.com/pages-themes/cayman/blob/master/_layouts/default.html
Expanded out the jekyll parts to make some plain html:
https://github.com/jcupitt/libvips/blob/gh-pages/_layouts/api-default.html
Then ran this tiny bit of ruby to replace the children of main-content with the children of `<body>` in the gtk-doc output:
https://github.com/jcupitt/libvips/blob/gh-pages/gen-api.rb
Producing pages like this:
http://jcupitt.github.io/libvips/API/current/VipsImage.html
It seems to work well, though it would have been nice to have been able to just use the jekyll template unexpanded.https://gitlab.gnome.org/GNOME/gtk-doc/-/issues/34Make gtk-doc easier to use from build systems other than automake2018-05-22T13:10:28ZBugzillaMake gtk-doc easier to use from build systems other than automake## Submitted by Jussi Pakkanen `@jpakkane`
**[Link to original bug (#758313)](https://bugzilla.gnome.org/show_bug.cgi?id=758313)**
## Description
Currently gtk-doc seems to share some functionality between core gtk-doc binaries and ...## Submitted by Jussi Pakkanen `@jpakkane`
**[Link to original bug (#758313)](https://bugzilla.gnome.org/show_bug.cgi?id=758313)**
## Description
Currently gtk-doc seems to share some functionality between core gtk-doc binaries and the automake module snippet that drives it. Tracing what commands Make invokes reveals stuff like copying files between source and build trees, copying version.entities to html dirs and so on.
Trying to replicate what it does is difficult, especially since sometimes you need to copy xml and definition files from the source tree to build tree, because gtkdoc seems to do different things based on where said files reside. (Sometimes it does not read them from source tree but does from the build tree.) Some commands also seem to have a requirement that they are executed in a specific directory.
It would make things easier if this complexity could be pushed into gtk-doc binaries so it is there only once and all build systems can just invoke it.
As an example, suppose the project root is at /proj, the header files to scan are in /proj/src, documentation files (proj-docs.sgml and the like) are in /proj/doc and the build tree is at /proj/build.
To generate docs, one should be able to run just one command like this (note that cwd can be anything). I'm using absolute paths, but relative ones should work just the same.
gtkdocv2 --docdir=/proj/doc --outdir=/proj/build/doc --scandir=/proj/src --output-format=html --main-file=proj-docs.sgml [other conf flags here]
The main program should then take care of calling all the subcommands in the proper way.https://gitlab.gnome.org/GNOME/gtk-doc/-/issues/33GTK-DOC: Detects macro as function instead of value2018-05-22T13:10:14ZBugzillaGTK-DOC: Detects macro as function instead of value## Submitted by Sebastian
**[Link to original bug (#754220)](https://bugzilla.gnome.org/show_bug.cgi?id=754220)**
## Description
Created attachment 310154
Macro recognized as function.
I am trying to document a macro with gtk-doc, ...## Submitted by Sebastian
**[Link to original bug (#754220)](https://bugzilla.gnome.org/show_bug.cgi?id=754220)**
## Description
Created attachment 310154
Macro recognized as function.
I am trying to document a macro with gtk-doc, the macro uses parenthesis around the macro definition, and this causes gtk-doc to recognize the macro as a function, which it is not.
Here is an example:
/**
* MY_CLASS_A:
*
* Some A
**/
#define MY_CLASS_A 0
/**
* MY_CLASS_B:
*
* Some B
**/
#define MY_CLASS_B 1
/**
* MY_CLASS_FOO:
*
* Or of A and B
**/
#define MY_CLASS_FOO (MY_CLASS_A|MY_CLASS_B)
If I compile this, then resulting document lists MY_CLASS_FOO under the category "Functions".
Now interestingly, if I change the macro, such that I break the line immediately after the macro name with a backslash, and place the remaining parts of the macro onto the next line, then the macro is correctly recognized and placed in the "Types and Values" section:
/**
* MY_CLASS_BAR:
*
* Or of A and B
**/
#define MY_CLASS_BAR \
(MY_CLASS_A|MY_CLASS_B)
My guess is that gtk-doc does differentiate between 'MACRO()' and 'MACRO ()' and thus interprets both as being a function, but in fact function macros are not allowed to have a space between their name and the parenthesis. Thus 'MACRO ()' is not a function.
In case this is not a bug and I am mistaken about something, then I would love if you could clarify this case in the documentation of gtk-doc, and explain if there is a way to explicitly tell gtk-doc that this case is not a function macro.
**Attachment 310154**, "Macro recognized as function.":
![Selection_028](/uploads/72a9dbcced6dab0a4a21e3b768550598/Selection_028.png)https://gitlab.gnome.org/GNOME/gtk-doc/-/issues/32Allow multiple namespaces2018-05-22T13:09:59ZBugzillaAllow multiple namespaces## Submitted by Emmanuele Bassi `@ebassi`
**[Link to original bug (#749577)](https://bugzilla.gnome.org/show_bug.cgi?id=749577)**
## Description
The --name-space argument to gtkdoc-mkdb should allow specifying multiple namespaces, f...## Submitted by Emmanuele Bassi `@ebassi`
**[Link to original bug (#749577)](https://bugzilla.gnome.org/show_bug.cgi?id=749577)**
## Description
The --name-space argument to gtkdoc-mkdb should allow specifying multiple namespaces, for libraries that have them in the same shared object.
For instance: Cally is a sub-API inside the Clutter shared library.
A simple solution would be to accept multiple `--name-space` arguments and make the $NAME_SPACE variable an array; then, iterate over every element of the array when doing matching.https://gitlab.gnome.org/GNOME/gtk-doc/-/issues/31wip concept: move away from gtkdocize2018-06-24T12:17:52ZBugzillawip concept: move away from gtkdocize## Submitted by Allison (desrt)
**[Link to original bug (#744864)](https://bugzilla.gnome.org/show_bug.cgi?id=744864)**
## Description
Here are some changes that should allow modules to move away from using
gtkdocize.
Instead, you ...## Submitted by Allison (desrt)
**[Link to original bug (#744864)](https://bugzilla.gnome.org/show_bug.cgi?id=744864)**
## Description
Here are some changes that should allow modules to move away from using
gtkdocize.
Instead, you just need to add this in your docs/ Makefile.am:
if HAVE_GTK_DOC
include $(GTK_DOC_MAKEFILE)
dist-hook: # do not remove!
endif
in place of the normal hard-coded include.
Most of the disruption here is caused by the fact that the make fragment
is no longer copied into the tree and is therefore no longer available
at autoreconf time. That means that we have to port the Makefile from
being an automake fragment to working in pure make.
The 'dist-hook:' hack is required because automake will fail to emit the
hook at all if it doesn't see someone using it (and it won't see it in
the included makefile, as mentioned above). It would be better to move
away from using the dist hook entirely, but there are two complications:
1) it's not entirely clear what the role of gtkdoc-rebase is here or if
it's even required anymore (it seems not to be)
2) it will be awkward to know which html files to install if those
files did not exist when make was invoked (ie: if the user skips
'make' and just goes straight to 'make install')https://gitlab.gnome.org/GNOME/gtk-doc/-/issues/30Force user to provide replacement API with Deprecated tag2018-05-22T13:09:15ZBugzillaForce user to provide replacement API with Deprecated tag## Submitted by Philip Withnall `@pwithnall`
**[Link to original bug (#744055)](https://bugzilla.gnome.org/show_bug.cgi?id=744055)**
## Description
It seems to be common for people to use the ‘Deprecated’ tag and just provide a vers...## Submitted by Philip Withnall `@pwithnall`
**[Link to original bug (#744055)](https://bugzilla.gnome.org/show_bug.cgi?id=744055)**
## Description
It seems to be common for people to use the ‘Deprecated’ tag and just provide a version number. That’s quite unhelpful for anyone reading the documentation for a deprecated function, because they would also like to know what API replaces it, and why it was deprecated in the first place.
I suggest that gtk-doc make its ‘Deprecated’ tag more explicit, with the format:
Deprecated: version: replacement-API: Description which is a full sentence.
The version and replacement-API would be required. The replacement-API should be the name of another symbol in the documentation, so it can be linked to; or it may be ‘no-replacement’ to explicitly indicate there is no replacement.
The description would also be required. Maybe gtk-doc should throw a warning if it’s less than 30 characters long, or something like that? Or is that too strict?
This change is going to break existing modules until they properly document their deprecations, and is probably going to annoy people at release time when they build with --enable-gtk-doc for the first time in a while. It might be an idea to add this as a check in gtkdoc-check for one cycle first, before enabling it as a fatal error from gtkdoc-scan.
Version: 1.21https://gitlab.gnome.org/GNOME/gtk-doc/-/issues/29gdbus-codegen integration for D-Bus API documentation2018-05-22T13:09:07ZBugzillagdbus-codegen integration for D-Bus API documentation## Submitted by Philip Withnall `@pwithnall`
**[Link to original bug (#743294)](https://bugzilla.gnome.org/show_bug.cgi?id=743294)**
## Description
Currently, people have to write their own build rules for generating Docbook files f...## Submitted by Philip Withnall `@pwithnall`
**[Link to original bug (#743294)](https://bugzilla.gnome.org/show_bug.cgi?id=743294)**
## Description
Currently, people have to write their own build rules for generating Docbook files from D-Bus interface XML files using gdbus-codegen. They then have to tie that in to gtk-doc in the docs.xml file and gtk-doc.make.
It would be useful if there were a macro which made this easier. It could either come with GDBus, in which case the integration with gtk-doc would have to be very loose, or it could come with gtk-doc. I suggest the latter, but it could be argued either way.
Proposal:
1. Add a DOC_DBUS_INTERFACE_XML input variable to gtk-doc.make. Add a DOC_DBUS_INTERFACE_PREFIX variable too.
2. For each of the listed files, it runs
gdbus-codegen --interface-prefix $(DOC_DBUS_INTERFACE_PREFIX) --xml-files=$(xml_file)
and puts the output in $(builddir)/xml
3. Build dependencies are updated so documentation is correctly regenerated if any of the interfaces change. The interface output files should be cleaned as appropriate.
4. gtkdoc-check is updated to check that all DOC_DBUS_INTERFACE_XML files are <xi:include>d into $(DOC_MAIN_SGML_FILE).https://gitlab.gnome.org/GNOME/gtk-doc/-/issues/28Add an easy way to license documentation2018-05-22T13:08:10ZBugzillaAdd an easy way to license documentation## Submitted by Philip Withnall `@pwithnall`
**[Link to original bug (#742580)](https://bugzilla.gnome.org/show_bug.cgi?id=742580)**
## Description
People very rarely make it obvious what license their gtk-doc documentation is under...## Submitted by Philip Withnall `@pwithnall`
**[Link to original bug (#742580)](https://bugzilla.gnome.org/show_bug.cgi?id=742580)**
## Description
People very rarely make it obvious what license their gtk-doc documentation is under. Typically, it’s under the same license as the code it was generated from (otherwise you raise some interesting questions about whether the documentation comments in the source code are dual licenced). This should be made a bit more obvious in the generated documentation, especially in the HTML documentation which is often copied to multiple sites.
How about adding a DOC_LICENSE variable to gtk-doc.make which passes some magic flags into the various gtkdoc-* utilities to:
1. Add schema.org metadata to the HTML output: http://schema.org/license
2. Add rel="license" microformat to the HTML output: http://microformats.org/wiki/rel-license
3. Add itemref="licenses" microdata to the HTML output: http://www.w3.org/TR/microdata/#attr-itemref
4. Add CC RDF metadata to the HTML output: https://wiki.creativecommons.org/Metadata
5. Add CC RDF metadata to the DocBook output: https://wiki.creativecommons.org/Metadata
6. Add a `<copyright>` element to the DocBook output: http://www.docbook.org/tdg/en/html/copyright.html
7. Add CC XMP metadata to the PDF output: https://wiki.creativecommons.org/XMP
8. Add a brief bit of licence text to the bottom of the index page of each output format stating the licence name and a link to the licence text. Might also want to include the full licence text somewhere, to handle the common case where the documentation is copied separately from the source code tarball?
DOCBOOK_LICENSE would accept various well-defined values, e.g. the ‘Short Name’ values from https://fedoraproject.org/wiki/Licensing:Main?rd=Licensing#Good_Licenses_2.https://gitlab.gnome.org/GNOME/gtk-doc/-/issues/27Linking to a section in a DocBook file is broken2020-09-11T19:19:01ZBugzillaLinking to a section in a DocBook file is broken## Submitted by Volker Sobek `@vsobek`
**[Link to original bug (#728283)](https://bugzilla.gnome.org/show_bug.cgi?id=728283)**
## Description
While looking at the remaining non-markdown links in the glib docs (the .h files still hav...## Submitted by Volker Sobek `@vsobek`
**[Link to original bug (#728283)](https://bugzilla.gnome.org/show_bug.cgi?id=728283)**
## Description
While looking at the remaining non-markdown links in the glib docs (the .h files still have some) I stumbled across this: All links of the form
`<link linkend="extending-gio">`Extending GIO`</link>`
seem to be broken for many versions (at least in every version available at https://developer.gnome.org/gio/).
In the current 2.40.x version it became obvious since in the .h files these links are not converted to markdown links yet (so they show up literally with '<link...' while in previous versions the link was just ignored during the doc generation since it didn't exist.
The errors when generating the docs look like:
html/GVfs.html:350: warning: no link for: 'extending-gio' -> (Extending GIO).https://gitlab.gnome.org/GNOME/gtk-doc/-/issues/26Prebuilt gtk-doc docs are not installed when we run an out-of-source build2018-05-26T19:34:23ZBugzillaPrebuilt gtk-doc docs are not installed when we run an out-of-source build## Submitted by Pacho Ramos `@pachoramos1`
Assigned to **gtk..@..tk.org**
**[Link to original bug (#719446)](https://bugzilla.gnome.org/show_bug.cgi?id=719446)**
## Description
When builddir!=srcdir gtk api docs from tarball don't...## Submitted by Pacho Ramos `@pachoramos1`
Assigned to **gtk..@..tk.org**
**[Link to original bug (#719446)](https://bugzilla.gnome.org/show_bug.cgi?id=719446)**
## Description
When builddir!=srcdir gtk api docs from tarball don't get installed :/
Thanks a lot for solving this problem
Version: 1.21https://gitlab.gnome.org/GNOME/gtk-doc/-/issues/25gtkdoc-fixxref: Add an --ignore-list option2018-05-22T13:07:33ZBugzillagtkdoc-fixxref: Add an --ignore-list option## Submitted by Damien Lespiau
**[Link to original bug (#690941)](https://bugzilla.gnome.org/show_bug.cgi?id=690941)**
## Description
Created attachment 232449
gtkdoc-fixxref: Add an --ignore-list option
Some functions have types f...## Submitted by Damien Lespiau
**[Link to original bug (#690941)](https://bugzilla.gnome.org/show_bug.cgi?id=690941)**
## Description
Created attachment 232449
gtkdoc-fixxref: Add an --ignore-list option
Some functions have types from external libraries without gtk-doc
documentation and thus impossible to cross-reference. With this patch
gtk-doc offers an option to ignore those types and not warn about them
when encountered.
A step in the quest to get Cogl's gtk-doc generation warning free with:
--ignore-list=HWND,MSG,SDL_Event,XEvent,Display
Bike-shedding on the option name and details that I have missed are more than welcomed.
**Patch 232449**, "gtkdoc-fixxref: Add an --ignore-list option":
[0001-gtkdoc-fixxref-Add-an-ignore-list-option.patch](/uploads/5e777f9e694db40ffd195dbdd080d2a8/0001-gtkdoc-fixxref-Add-an-ignore-list-option.patch)https://gitlab.gnome.org/GNOME/gtk-doc/-/issues/24Enable hyperlinking for default values2018-05-22T13:07:05ZBugzillaEnable hyperlinking for default values## Submitted by Kevin Connor ARPE
**[Link to original bug (#690717)](https://bugzilla.gnome.org/show_bug.cgi?id=690717)**
## Description
Created attachment 232216
Git patch
This change affects object properties.
Example default...## Submitted by Kevin Connor ARPE
**[Link to original bug (#690717)](https://bugzilla.gnome.org/show_bug.cgi?id=690717)**
## Description
Created attachment 232216
Git patch
This change affects object properties.
Example default values: NULL, TRUE, FALSE, PANGO_ALIGN_LEFT
Normally, they are shown in plain text. This patch will
add a hyperlink. If the default value is a number, such as 123,
it will not be hyperlinked.
Only default values that "look" like valid C identifiers
are hyperlinked.
~~**Patch 232216**~~, "Git patch":
[0001-Enable-hyperlinking-for-default-values.patch](/uploads/9cd31f9f960017fc48c6f70296f30a0f/0001-Enable-hyperlinking-for-default-values.patch)https://gitlab.gnome.org/GNOME/gtk-doc/-/issues/22Incorrect anchor generated for GBoxed typedef in the same file as a class2018-05-22T13:06:15ZBugzillaIncorrect anchor generated for GBoxed typedef in the same file as a class## Submitted by Philip Withnall `@pwithnall`
**[Link to original bug (#682401)](https://bugzilla.gnome.org/show_bug.cgi?id=682401)**
## Description
If a single C file/H file pair defines a GObject class as normal, but also has a typ...## Submitted by Philip Withnall `@pwithnall`
**[Link to original bug (#682401)](https://bugzilla.gnome.org/show_bug.cgi?id=682401)**
## Description
If a single C file/H file pair defines a GObject class as normal, but also has a typedef of a struct which is registered as a GBoxed type with GObject, an extraneous `<anchor>` element will be generated for the typedef in the gtk-doc XML for that file. It’s extraneous because a `<refsect>` will also be generated for the typedef, with the same ID. The IDs will clash.
For example, the following H file (full version here: http://git.gnome.org/browse/totem-pl-parser/tree/plparse/totem-pl-parser.h):
typedef struct {
…
} TotemPlParserClass;
/**
* TotemPlParserMetadata:
*
* …
*/
typedef GHashTable TotemPlParserMetadata;
with the following C file (full version here: http://git.gnome.org/browse/totem-pl-parser/tree/plparse/totem-pl-parser.c):
GType
totem_pl_parser_metadata_get_type (void)
{
…
GType g_define_type_id = g_boxed_type_register_static (
g_intern_static_string ("TotemPlParserMetadata"),
(GBoxedCopyFunc) g_hash_table_ref,
(GBoxedFreeFunc) g_hash_table_unref);
…
}
will generate the following XML:
<refsynopsisdiv id="TotemPlParser.synopsis" role="synopsis">
<title role="synopsis.title">Synopsis`</title>`
<anchor id="TotemPlParserMetadata"/>
`<synopsis>`
#include <totem-pl-parser.h>
…
`<refsect2 id="TotemPlParserMetadata" role="typedef">`
`<title>`TotemPlParserMetadata`</title>`
`<indexterm zone="TotemPlParserMetadata">``<primary>`TotemPlParserMetadata`</primary>``</indexterm>`
`<programlisting>`typedef GHashTable TotemPlParserMetadata;
`</programlisting>`
`</refsect2>`