On Wed, 2009-03-04 at 12:03 +0200, Stefan Kost wrote:
> Maciej Piechotka schrieb:
> > On Fri, 2009-02-20 at 10:37 +, Alberto Ruiz wrote:
> >
> >> 2009/2/20 Maciej Piechotka :
> >>
> >>> Eugene Gorodinsky writes:
> >>>
> >>>
> Hi all
>
> Since you guys are discussi
>>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 :
> Maciej Piechotka schrieb:
>> On Fri, 2009-02-20 at 10:37 +, A
Stefan Kost wrote:
> 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?do
Maciej Piechotka schrieb:
> On Fri, 2009-02-20 at 10:37 +, Alberto Ruiz wrote:
>
>> 2009/2/20 Maciej Piechotka :
>>
>>> Eugene Gorodinsky writes:
>>>
>>>
Hi all
Since you guys are discussing the redesign of the gtk+ website, I'd
like to propose an idea that I
On Fri, 2009-02-20 at 10:37 +, Alberto Ruiz wrote:
> 2009/2/20 Maciej Piechotka :
> > Eugene Gorodinsky 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
Stefan Kost writes:
> Eugene, Maciej,
>
> I've have some concept for the gtk-doc side of things. For the server side
> I've
> ideas too, if you want to join, there is #gtkdoc on gimpnet irc. Lets discuss
> there. Need to talk to the web-site hackers to come up with the easiest/best
> way
> to i
Eugene, Maciej,
I've have some concept for the gtk-doc side of things. For the server side I've
ideas too, if you want to join, there is #gtkdoc on gimpnet irc. Lets discuss
there. Need to talk to the web-site hackers to come up with the easiest/best way
to integrate.
Stefan
Maciej Piechotka sch
Mathias Hasselmann wrote:
Am Donnerstag, den 19.02.2009, 10:33 -0500 schrieb Dominic Lachowicz:
That's hard-ish to do today. GTK+'s documentation is generated in
large part by scanning comments in C code, which a program then turns
into HTML. Any proposal would require a way to keep the Wiki and
Le vendredi 20 février 2009, à 14:32 +0200, Stefan Kost a écrit :
> Would thank be enough for a GSoC project? I would mentor it, but I would
> rather
> juck hack with someone diretly on it? Who joins?
I'd rather have the SoC project be the web interface that makes the doc
editable. Maybe based on
Stefan Kost writes:
> hi,
>
> Maciej Piechotka schrieb:
>> Eugene Gorodinsky 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 a
As I understood the way this thing would work is: after the gtk-doc
tool genereates documentation a cgi is executed that would add the new
version of the documentation to the wiki database, and whenever the
documentation in the wiki gets modified, another cgi is executed that
would change the docum
hi,
Maciej Piechotka schrieb:
> Eugene Gorodinsky 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
>> ha
Eugene Gorodinsky 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+ ap
On Thu, 2009-02-19 at 16:56 +0100, Mathias Hasselmann wrote:
> Am Donnerstag, den 19.02.2009, 10:33 -0500 schrieb Dominic Lachowicz:
> > That's hard-ish to do today. GTK+'s documentation is generated in
> > large part by scanning comments in C code, which a program then turns
> > into HTML. Any pro
A way to overcome that, would be to put a warning on the wiki page
whenever the documentation for a function is updated, so that the
users could see the updated comment in the code and update the
documentation accordingly.
P.S. Sorry for sending the message twice
2009/2/19 Dominic Lachowicz :
>
Am Donnerstag, den 19.02.2009, 17:52 +0200 schrieb Eugene Gorodinsky:
> Have there been cases where documentation for some function was
> changed after that function appeared in the stable version?
Yes, this happens frequently: Spelling errors, explanations of
limitations, code examples, usage sce
Am Donnerstag, den 19.02.2009, 10:33 -0500 schrieb Dominic Lachowicz:
> That's hard-ish to do today. GTK+'s documentation is generated in
> large part by scanning comments in C code, which a program then turns
> into HTML. Any proposal would require a way to keep the Wiki and the C
> comments in-sy
Yes. The most common example I can think of is when a function is deprecated.
On Thu, Feb 19, 2009 at 10:52 AM, Eugene Gorodinsky
wrote:
> Have there been cases where documentation for some function was
> changed after that function appeared in the stable version?
>
> 2009/2/19 Dominic Lachowicz
Have there been cases where documentation for some function was
changed after that function appeared in the stable version?
2009/2/19 Dominic Lachowicz :
> That's hard-ish to do today. GTK+'s documentation is generated in
> large part by scanning comments in C code, which a program then turns
> in
That's hard-ish to do today. GTK+'s documentation is generated in
large part by scanning comments in C code, which a program then turns
into HTML. Any proposal would require a way to keep the Wiki and the C
comments in-sync.
On Thu, Feb 19, 2009 at 10:28 AM, Eugene Gorodinsky
wrote:
> Hi all
>
>
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?
21 matches
Mail list logo
