GTK-Doc Future
#151 (closed)
IssueIssue #151 (closed) was closed to early.
Sure commit 28fb91ac was clumsy but it has been corrected.
Emmanuele Bassi says: "It is an abandoned project" and he suggets to archive it. No, GLib, GTK abandoned GTK-Doc. GLib, GTK are not the center of the universe. So GTK-Doc must stay alive. Should GTK-Doc adopt GTK disruptive evolution? No.
Michael Catanzaro, puts his $0.02 in thinkig that issues are not good places for open-ended discussion. He is wrong. In Gitlab, issues are the place to discuss. Where are they otherwise? GNOME Discourse?
Intend
GTK-Doc has a past, a present and a future.
GTK-Doc must stay alive and we need a plan for that. It shouldn't go to the cemetery but to a retirement home.
Accept no more enhancement. Document the existing bugs. Turn them to a feature.
In terms found in "Fostering a culture that values stability and reliability", respond to external changes.
Use cases
-
Bob is using GTK-Doc in his project. He likes the HTML output and finds it more practical than the one produced by say, GI-Docgen. He should be able to continue using it as long as he is happy with it.
-
Alice wants to revive an old GTK project. It uses an old GTK version, Autotools, GTK-Doc and other old technologies. She wants to replace them with Meson, GI-Docgen and other new technologies. At start, GTK-Doc won't be a problem. It works. She could concentrate on more crucial issues. Later, she could turn to the API documentation.
-
foo
is a GLib software that offer a library and some tools. Charles wants to write an "foo
manual" to explain how to usefoo
to achieve great things. He chooses DocBook as a file format. In some part of the book, he wishes to expose the API. Some tool to generate DocBook API documentation from C sources would be very helpful.