Hi, The documentation seems to be generated with Doxygen based on the current CSS template of the GTKmm Class Reference. You can built a Doxygen configuration file in which you define how to display the information, which informations are displayed or which files is used as CSS template. You should read the Doxygen documentation because there are several rules/conventions to document properly a source code. If the GTKmm Class Reference is generated with the Doxygen, we could probably increase its quality providing a new Doxygen configuration files or/and CSS file. Doxygen can also generate UML schematics of a function or a sequence of calls and a lot more. Regards Marco Dos Santos Oliveira EBU/European Broadcasting Union Technology and Innovation Department From: gtkmm-list [mailto:gtkmm-list-bounces gnome org] On Behalf Of Jiergir Ogoerg Hi, I've worked with gtkmm and used its documentation for like 2 years, at first I thought I'll get used to its issues but it still didn't happen. Coming from Java I see here and there obvious and frustrating issues, are these by design or can actually be improved? A few examples: - List methods alphabetically. The most obvious and irritating one. By far. In Java I don't need to read the whole list when searching for a given function nor bring up a search dialog box to search for it, I just look down, to say, "set_size(..)" and see if it's there, if not I know there's no such method - fast, intuitive and simple. Currently the gtkmm documentation seems to list the methods chaotically, i.e. the method "activate()" for Gtk::MenuItem is listed in the middle of the functions list, while in Java it would be the first one. The docs seem to try to compensate that by putting related methods together, but to me this isn't helpful at all. - Differentiate constructors from methods more clearly, put them into different (HTML) tables, make the tables more professional. Here's a screenshot of how Java does this: - The layout in general isn't well shaped, maybe it's the CSS to blame. In Java for example the methods are listed in rows colored differently (zebra style) like in a file browser, which is handy. - If a method is deprecated put a bold "deprecated since v x.x" right near its name, not in the description section - it's handier this way, as in Java. I don't have experience creating/designing documentation, so I'm not sure I could do this if anyone assigns me to do this myself, but I'd be very happy if anyone can do this and push these changes upstream. I could suggest further improvements if there's people willing to do this.
************************************************** |