>>implements a fast way to get from symbol to docblob A database seems like good idea here + and tools to sync with the SVN (is there a way to run a script on the server side when a file has been submitted?)
2009/3/4 Stefan Kost <enso...@hora-obscura.de>: > Maciej Piechotka schrieb: >> On Fri, 2009-02-20 at 10:37 +0000, Alberto Ruiz wrote: >> >>> 2009/2/20 Maciej Piechotka <uzytkown...@gmail.com>: >>> >>>> Eugene Gorodinsky <e.gorodin...@gmail.com> writes: >>>> >>>> >>>>> Hi all >>>>> >>>>> Since you guys are discussing the redesign of the gtk+ website, I'd >>>>> like to propose an idea that I have. I've seen quite a lot of comments >>>>> saying gtk+ documentation isn't as good as qt's. What do you think of >>>>> having a wiki that documents all of gtk+ api? >>>>> >>>> I'm not sure but I guess that it would be possible to integrate it >>>> somehow with SVN(or, even better, git/bzr/...). The wiki syntax could be >>>> translated into gtkdoc. >>>> >>> Gtkdocs are stored in the source code headers, >>> >> >> BTW - this idea, which I personally like, is not common. Gtk-doc >> comments are usually placed in source files. The exception is for >> example webkit-gtk (or at least used to be). >> >> >>> that helps developers >>> to keep documentation up to date. >>> That means that pushing documentation upstream is not possible. >>> >>> What we could do is to have a queue of contributions/feedback and >>> notify the module maintainer about it. >>> >>> >> >> I never thought about pushing it into trunk directly. Next paragraph of my >> mail is: >> "With svn: The developer/maintainer of wiki could download wiki syntax as >> a patch, apply it and commit." >> >> And the merging usually is quite possible: >> - Find symbol before which there is comment started by /** (or any other >> - Insert the generated doc/update it/... >> - Diff with previous >> In some cases it will need to be handled manually - but I guess that in 99% >> it will not. >> >> Regards >> >> > Hi, > > I put some notes online: > http://live.gnome.org/DocumentationProject/GtkDocFuture#head-a95d3540bfa9b29299058c0e13b162ce2a772da7 > Should the prototype submit patches to bugzilla? > > subtasks that I could need help with: > 1) start a basic cgi for library.gnome.org (if I do it its gonna be > perl, but I don't care so much) > * have a hasmap there docmodule->sourcedir > * implements a fast way to get from symbol to docblob > * when calling edit.cgi?docmodule=glib&symbol=g_object_new > * show a textfield with the docs for it > > 2) write a bugzilla_submit_patch function in for the above cgi (see link > for how bugbuddy is doing it). > > 3) build-brigade - anyone reading this? whats the chances of getting a > doc-builder, where we could also run this cgi? > > Stefan > _______________________________________________ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-devel-list > _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list