Re: gobject tutorial merge

[Mathieu Lacage <mathieu gnome org>]

I won't comment on the patches because they are really big. Most
notably, you included in the patches a bunch of space-related changes
which do not contain any semantic information and large amounts of
mechanic <link> additions for <function> tags which I am not really
interested in reviewing. It would make a lot of sense if you could try
to avoid doing this for the sake of easy review.

Instead, here is a patch to the latest version in CVS I think you should
consider. It fixes mostly typos. I leave you free to commit it or not.

Also, I noticed that you changed the name of a few type names in the
sample code included in the howto part. If you import (you _really_
should do it) the actual real sample code somewhere in the glib/gobject
source code, please, make sure to update it also so as to avoid any
discrepency between the two versions.

thanks for your work,

regards,
Mathieu

? patch
Index: tut_tools.xml
===================================================================
RCS file: /cvs/gnome/glib/docs/reference/gobject/tut_tools.xml,v
retrieving revision 1.2
diff -u -r1.2 tut_tools.xml
--- tut_tools.xml	22 Apr 2005 10:27:37 -0000	1.2
+++ tut_tools.xml	3 May 2005 10:45:14 -0000
@@ -1,7 +1,7 @@
 <partintro>
 	<para>
 		Several useful developer tools have been build around GObject technology.
-		Next sections briefly introduce them and link to the respective project pages.
+		The next sections briefly introduce them and link to the respective project pages.
 	</para>
 </partintro>
 
@@ -10,14 +10,15 @@
 
   <para>
 		Writing gobjects can be a tedious task. It requires a lot of typing and just
-		doing copy and paste needs care. On obvious idea is to use some sort of 
-		templates for the class skelletons. Then a tool could generate the real c
-		files from them.
-		<ulink url="http://www.5z.com/jirka/gob.html";>GOB/</ulink> (or GOB2) is suc
-		h a tool. It is a preprocessor for making GObjects with inline C code so
+		doing copy and paste requires being very careful. One obvious idea is to use some sort of 
+		templates for the class skeletons and then run them through a special tool to generate the real c
+		files.
+		<ulink url="http://www.5z.com/jirka/gob.html";>GOB/</ulink> (or GOB2) is such
+		a tool. It is a preprocessor for making GObjects with inline C code so
 		that generated files are not edited.
-		Syntax is inspired by Java and Yacc or Lex. The implementation is
-		intentionally kept simple, and no C actual code parsing is done.
+		The syntax is inspired by Java, Yacc and Lex. The implementation is
+		intentionally kept simple, and the inline C code provided by the user
+                is not parsed.
   </para>
 </chapter>
 
@@ -27,9 +28,9 @@
   <para>
     The reference counting scheme used by GObject does solve quite 
     a few memory management problems but also introduces new sources of bugs.
-    In large applications, finding the exact spot where a the reference count
+    In large applications, finding the exact spot where the reference count
     of an Object is not properly handled can be very difficult. Hopefully, 
-    there exist at a too named <ulink url="http://refdbg.sf.net/";>refdbg/</ulink>
+    there exist a tool named <ulink url="http://refdbg.sf.net/";>refdbg/</ulink>
     which can be used to automate the task of tracking down the location
     of invalid code with regard to reference counting. This application 
     intercepts the reference counting calls and tries to detect invalid behavior. 
@@ -71,6 +72,5 @@
   <ulink url="http://developer.gnome.org/arch/doc/authors.html";>documentation</ulink> 
   on how to setup and use gtk-doc in your
   project is provided on the gnome developer website.
-  gtk-doc generates
   </para>
 </chapter>