X-Git-Url: https://git.draconx.ca/gitweb/gob-dx.git/blobdiff_plain/8445442abc02fc325a9ce228759403113583818c..926b8d8fb3ecffe60f3eaefcd5ec40a5273251ce:/doc/gob2.1.in

diff --git a/doc/gob2.1.in b/doc/gob2.1.in
index f392384..dfd4016 100644
--- a/doc/gob2.1.in
+++ b/doc/gob2.1.in
@@ -57,10 +57,9 @@ changed (implies \-\-no\-touch\-headers).  Be careful with automake, see section
 PREVENTING SPURIOUS BUILDS.
 .TP
 .B \-\-no\-touch\-headers
-Don\'t touch the generated header file unless it really changed, this avoids
-spurious rebuilds, but can confuse some make systems (automake in particular),
-so it is not enabled by default.  Private header is still touched even if
-unchanged however.
+Don\'t touch any generated header file unless that file really changed.
+This avoids spurious rebuilds, but can confuse some make systems so it is not
+enabled by default.
 .TP
 .B \-\-always\-private\-header
 Always create a \fB<basename>-private.h\fR file, even if it would be empty.
@@ -238,6 +237,17 @@ For example:
 To make an abstract class (to pass G_TYPE_FLAG_ABSTRACT) add \'(abstract)\'
 before the curly braces above.  This works since version 2.0.13.
 
+.PP
+To make a simple dynamic class which can be registered with a GTypeModule,
+add \`(dynamic)\' to the class header.
+This will cause a type registration method to be defined, which you would
+normally call from the load method of a GTypeModule.
+In the above example, the registration function will look like
+.nf
+
+  void gtk_new_button_register_type(GTypeModule *type_module)
+
+.fi
 .SH DATA MEMBERS
 .PP
 There are five types of data members.  Three of them are normal data members,
@@ -1054,6 +1064,21 @@ a specific method of the interface, just add \'interface <typename>\'
 before the method definition.  The method can, and probably should be,
 private.
 .PP
+Interface methods behave very similarly to virtual/override methods.
+As with override methods, you can use PARENT_HANDLER in the definition of an
+interface method to call the implementation of the same interface method in
+a parent class.
+.PP
+The NAME_parent_iface variable may be used to access the complete interface
+structure from a parent class, where NAME is the implemented interface (with
+colons replaced by underscores).
+This enables access to the full parent implementation of an interface.
+For example, if a class implements the Gtk:Tree:Model interface then the
+implementation of the same interface in the parent class is available via
+the Gtk_Tree_Model_parent_iface pointer.
+If an interface is not implemented in the parent class, then the corresponding
+parent_iface value will be a null pointer.
+.PP
 The following example implements a new object, that implements the
 Gtk:Tree:Model interface and implements the get_flags method of that
 interface.  Do note that except for standard (GTK+ and glib) specific