Well, a better topic name I did not find out, sorry for that.
Earlier documentation showed the return type of the functions and I could easily sort them if I had, for example, to find out which functions returned gboolean or char*…and so on.
Now if I need to find out for example in the GtkWindow documentation which functions are returning let’s say gbooblean I cannot do that anymore because the return type is not listed anymore:
Why is that?
Is there an alternative of that ability to search only after a particularly return type?
But, yes: the index does not list the full prototype, because that scales pretty badly when it comes to complex functions that take more than one argument, and makes the index page a lot more busy to visually scan for things; heavier to download on limited bandwidth; and harder to map to different languages, as the C API reference is used as a fallback by various bindings.
You should search for specific keywords, like “window title”, and then go to the method that you’re interested in, and see the full declaration.
How could you possibly “sort” functions in gtk-doc? The order in the list of declarations was hard coded by the author of the documentation, and the generated documentation had no search capabilities, and no way to go back to the list of declarations once you went to a specific function.
Of course there isn’t, because that’s not something a documentation website is supposed to cater to or support.
You’re screen-scraping the HTML generated by a tool—which was the case even for the reference generated by gtk-doc—and you assume that a) it’s going to be stable across releases b) it’s going to be machine readable, and now you’re complaining that your screen-scraper is broken? Do you understand how that’s completely unsupportable?
I fail to understand the relevance of this statement.
The documentation website is geared towards people reading it, and finding how things work. It’s not designed for making it possible to be machine readable.
We already have a machine readable format that describes our API: it’s called gobject-introspection, and it’s what we use to generate the documentation, as well as language bindings. The format is stable, the output is stable, and it’s meant to be parsed by computers. You should use that.
You cannot have any expectation that the generated HTML is going to be stable, even if we didn’t change the tool that generates the documentation.
My “it’s horrific” was directed to that particular “solution”.
I honestly care about people who want to read the documentation, not people who want to screen-scrape it; your script got broken because they were relying on something that was never meant to be relied upon—and I am not interested in catering to that particular use of our documentation.
If you want to do machine reading, we already offer you the tools and the file format for it. The documentation website is for human beings.
Yes, the documentation website has changed. The entire goal of the API reference is to present the API, and then let the reader “drill down” to specific pages; the documentation tool has stable, predictable links, and generates individual pages for each type, function, method, signal, property, etc. The index is not presenting the entire API for a page, or a bunch of symbols grouped together by some inscrutable criteria.
If you want to have a collection of C declarations, you should read the header files. If you want to search through the API using scripts, you should use the introspection data.
This sarcasm is uncalled for, unless you seriously think I never use the API reference.
Of course, but my tool was working simple because I had to past the URL and Search_String as arguments and worked fine, and those URLs were never memorized inside the program at all.