Fix a typo reported by Laurent Lemaitre. Tweak the GType section on instiable objects...

diff --git a/docs/reference/gobject/tut_gtype.xml b/docs/reference/gobject/tut_gtype.xml
index 0ba06be15bd8cbff22a3c60849050c761e1bfc4d..fc9d4a26e9f45c0edc31bae0525a9e83be9f3a10 100644 (file)
--- a/docs/reference/gobject/tut_gtype.xml
+++ b/docs/reference/gobject/tut_gtype.xml
@@ -541,15 +541,23 @@ The class initialization process is entirely implemented in
 
       <para>
        As many readers have now understood it, the base initialization/finalization process is
-       very similar to the C++ Constructor/Destructor paradigm. However, it is very different
-       in that, in C++, class constructors are automatically edited at compile 
-       time by the compiler to ensure that classes are correctly initialized before 
-       running the user-provided constructor code itself. With GObject, users must provide both 
-        the class and instance initialization functions.
-       Similarly, GTypes have no instance destruction mechanism. It is
+       very similar to the C++ Constructor/Destructor paradigm. The practical details are quite different
+        though and it is important not to get confused by the superficial similarities. Typically, what 
+        most users have grown to know as a C++ constructor (that is, a list of
+        object methods invoked on the object instance once for each type of the inheritance hierachy) does
+        not exist in GType and must be built on top of the facilities offered by GType. Similarly,
+        GTypes have no instance destruction mechanism. It is
        the user's responsibility to implement correct destruction semantics on top
        of the existing GType code. (this is what GObject does. See 
-       <xref linkend="chapter-gobject"></xref>)
+       <xref linkend="chapter-gobject"/>)
+      </para>
+
+      <para>
+       For example, if the object B which derives from A is instantiated, GType will only invoke the 
+       instance_init callback of object B while a C++ runtime will invoke the constructor of the object 
+       type A first and then of the object type B. Furthermore, the C++ code equivalent to the base_init 
+       and class_init callbacks of GType is usually not needed because C++ cannot really create object 
+       types at runtime.
       </para>
 
        <para>

diff --git a/docs/reference/gobject/tut_intro.xml b/docs/reference/gobject/tut_intro.xml
index b8bcb16592593620e8847dc0f5e8c4d09bdd7fc6..6a0d546ae25d4b4f0b97a99096b216c1815e5cf8 100644 (file)
--- a/docs/reference/gobject/tut_intro.xml
+++ b/docs/reference/gobject/tut_intro.xml
@@ -133,7 +133,7 @@ all the objects manipulated by the programmer. This so-called <emphasis>dynamic
 </footnote>
 
  library is then
-used by special generic glue code to automatically convert function parameters and function caling conventions
+used by special generic glue code to automatically convert function parameters and function calling conventions
 between different runtime domains.</para></listitem>
 </itemizedlist>
 The greatest advantage of the solution implemented by GType is that the glue code sitting at the runtime domain