The old developers documentation snapshot has been permanently retired, as all its content has effectively been moved to the new developers documentation website, or it’s irrelevant to anything that was released in the past 14 years.
Various redirections have already been put in place for API references that have been moved elsewhere, like Network Manager and the C++ bindings.
If there are missing references it mainly means that the corresponding libraries are not updating or publishing their documentation. Please, file an issue on their corresponding issue tracker.
developer.gnome.org [1] → developer-old.gnome.org [2] plus a new website at developer.gnome.org [3] (which is equal to [1]).
What about all the links that pointed to [1] and haven’t been updated to [2]?
The grep command that you posted only searches [2].
Edit: so if I understand correctly the [1] links are all redirected (either to [3] or outside), so it’s not a big problem to keep the old URLs around. Ideally the [1] links also need to be updated, but is not essential. (to search all the [1] links, a different method is necessary, by requesting the URL and detect if there is a redirection).
Don’t know but I fill like the old was very easy to navigate the new version is sometimes a little confusing. in the old version things was arranged by topic it was clear but with the new it is not…for example look at the “function” for GLib or Gtk it takes some time to find elements.
The old documentation of GLib and GTK were generated with GTK-Doc, now these projects use gi-docgen.
It was already discussed on Discourse. It seems to me that many people don’t like the change (me included). And API documentation is something essential for developers, so changing something as fundamental as that must be done carefully.
It seems to you because you’re looking only to the people that don’t like it, as confirmation bias.
It took nearly a decade of broken library-web and gtk-doc, and yet nobody stepped up to make something better, because nobody really cared, as long as they didn’t have to change anything.
In the meantime, everybody else moved over to different documentation platforms—from MSDN, to Swift, to Rust, to Python, to JavaScript. Yes, not everyone likes new things; nothing is ever going to be liked by everybody, and trying to serve everybody is a great way to make everybody differently unhappy.
If you think you can do better, feel free to do so, and put your money where your mouth is.
I find the presentation of gi-docgen a lot less relevant than the indirect benefits.
I liked some things about the output of gtk-doc, but the improvements to annotations, cross-linking and documentation comments in libraries just got better as a result of gi-docgen. Even if you don’t like gi-docgen it made it a lot easier to write other output generators.
There’s also nothing forcing projects to migrate to gi-docgen; most of us just are because we want to.
Before this retirement, these were documented at the developer-old subdomain. Now, the only way to learn about them is on third-party hosted copies of the old gtkdoc documentation, or at archive.org.
Is there anything we can do to have first-party hosting of information (in any form) about style properties and child properties? Or, could the current docs at least mention that they do not cover the complete public API of GTK3?
The reason I care about this is because I’ve developing against GTK for decades, and it seems wrong that I and others will remember documentation is more complete than what is available now. One assumes documentation to be comprehensive, and from this perspective the current docs effectively deny the existence of APIs and behaviors that I and others know to exist. Style properties are deprecated, but as far as I know child properties are not; there is no other way to achieve the behaviors that they specify. And deprecation is one thing; rewriting history is another. So I would really appreciate at least some visible note that the current form of the GTK3 documentation is not comprehensive, so that readers aren’t confused by the newer docs containing less information than the old ones.
And why does anyone still care about GTK3? Well, people still use it and develop against it. For example, the very first stable release of GIMP to use GTK3 came out 3 months ago. Retiring the complete docs a year prior to that seems premature.
That has never been true in the past, either. The GTK3 documentation was missing multiple symbols and descriptions.
In practice, if you want the old GTK3 API reference, with all its limitations, you can find it locally, in your system; distributors have not stopped building it and providing it as an additional package. If you are the one building GTK3, then you can also build and install the API reference.
GTK3 has not been ported to using introspection-based documentation, and it’s still using gtk-doc.
GIMP is but one consumer of the GTK API; and considering GIMP is still using GTK3 when everything else has moved to GTK4, a GIMP release is not a blocker for anything related to GTK.
I’m not asking to block anything, I’d just like to make the documentation hosted at gtk.org more comprehensive. I understand at this point that you are not interested in working with me toward that goal. I hope you change your mind in the future.