SoC-Status 2007/06/19
Here comes a new Summer of Code status report.
- I've increased my involvement with the GTK+ team: Took care about some GTK+ bugs. Got permissions to close bugs after applying reviewed patches (see: GtkTasks). During that process I've got more familiar with git-svn - had my first dcommits.
- Wasted time on extending libzip to support extracting PPMd compressed ZIP files. Having two important(?) features InfoZIP doesn't support, it seems about time to trigger libzip support in file-roller.
- The giant GtkBuilder patch has landed in GTK+ trunk. So I decided to resynch my extended-layout branch with the trunk. This is not the usual way to handle Subversion branches, but it should help me to avoid merge conflicts in the future.
- Finally came around to write real extended-layout code: The interface is there and GtkLabel implements get_baseline, testextendedlayout got new tests, autotestextendedlayout showed up as distcheck.
- Wasted quite some time by fighting with and waiting for gtk-doc to build documentation for GtkExtendedLayout: It found my new methods and added them to gtk-unused.txt, but I still had to manually move those declarations to gtk-sections.txt. Also had to register GtkExtendedLayout in gtk.types and to link it from gtk-docs.sgml. Clearly not state of the art. Extra annoyance points for xsltproc being incredibly slow.
Update: Learned from Federico and Matthias Clasen, that they usually comment out large parts of gtk-docs.sgml when doing documentation, well and that partly the Docbook stylesheets are too be blamed for the poor performance as they do alot of O(n^2) stuff.
hi,
did you know that there is a user-manual for gtk-doc that telles you what to do? In bugzilla is also a perl hack that worksaround the slowness of the docbook scripts. Its the automatic index generation which is slow. As gtk-doc knows the api it could produce the index in no time at all. The only downside is that if you define index entries in your handwritten sgml they would be lost (which I don't see as a critical issue).
Hi Stefan,
Cool, you've got the very first post on the new taschenorakel site! :-)
Back on topic: I know that there are is a user-manual for gtk-doc and I've read it several times. Problem is, that the steps needed to make gtk-doc work are that cumbersome, that at least I regularly forget the details. Guess I just don't use often enough. Well, and when generating the GTK+ docs not only index generation is slow. Insane amounts of time are needed for all pages of those docs. Would like to improve gtk-doc, once the new layout manager is in trunk. Problem: I am incredibly bad in reading and understanding Perl code. So I put my hope in Apple's clang frontend for LLVM: It shall be implemented as C++ library and therefore should allow creating of a much better documentation and introspection tool for GObject, than the current gtk-doc tool.
Well, and this all doesn't change the fact, that gtk-doc ate a lot of time from me.