scrubbed cameron patches

Original commit message from CVS:
scrubbed cameron patches

docs/manual/advanced-threads.xml

@@ -81,7 +81,7 @@
 
 /* eos will be called when the src element has an end of stream */
 void 
-eos (GstSrc *src, gpointer data) 
+eos (GstElement *src, gpointer data) 
 {
   GstThread *thread = GST_THREAD (data);
   g_print ("have eos, quitting\n");

docs/manual/basics-plugins.xml

@@ -1,23 +1,25 @@
 <chapter id="cha-plugins">
-  <title>What are Plugins</title>
+  <title>Plugins</title>
+  <!-- FIXME: introduce type definitions before this chapter -->
   <para> 
-    A plugin is a shared library that contains at least one of the following items:
+    A plugin is a shared library that contains at least one of the following
+    items:
   </para>
 
   <itemizedlist>
     <listitem>
       <para>
-        one or more elementfactories
+        one or more element factories
       </para>
     </listitem>
     <listitem>
       <para>
-        one or more typedefinitions
+        one or more type definitions
       </para>
     </listitem>
     <listitem>
       <para>
-        one or more autopluggers
+        one or more auto-pluggers
       </para>
     </listitem>
     <listitem>
@@ -27,19 +29,24 @@
     </listitem>
   </itemizedlist>
   <para> 
-    The plugins have one simple method: plugin_init () where all the elementfactories are
+    All plugins should implement one function, <function>plugin_init</function>,
-    created and the typedefinitions are registered.
+    that creates all the element factories and registers all the type
+    definitions contained in the plugin.
+    Without this function, a plugin cannot be registered.
   </para> 
   <para> 
-    the plugins are maintained in the plugin system. Optionally, the typedefinitions and 
+    The plugins are maintained in the plugin system. Optionally, the
-    the elementfactories can be saved into an XML representation so that the plugin system
+    type definitions and the element factories can be saved into an XML
-    does not have to load all available plugins in order to know their definition.
+    representation so that the plugin system does not have to load all
+    available plugins in order to know their definition.
   </para> 
 														  
   <para> 
     The basic plugin structure has the following fields:
   </para> 
   <programlisting>
+typedef struct _GstPlugin   GstPlugin;
+
 struct _GstPlugin {
   gchar *name;                  /* name of the plugin */
   gchar *longname;              /* long name of plugin */
@@ -57,7 +64,8 @@ struct _GstPlugin {
   </programlisting>
 
   <para> 
-    You can query a GList of available plugins with:
+    You can query a <classname>GList</classname> of available plugins with the
+    function <function>gst_plugin_get_list</function> as this example shows:
   </para> 
   <programlisting>
     GList *plugins;

docs/manual/init.xml

@@ -2,13 +2,14 @@
   <title>Initializing <application>GStreamer</application></title>
   <para> 
     When writing a <application>GStreamer</application> application, you can
-    simply include gst/gst.h to get access to the library functions.
+    simply include <filename class='headerfile'>gst/gst.h</filename> to get 
+    access to the library functions.
   </para> 
   <para> 
     Before the <application>GStreamer</application> libraries can be used
-    gst_init () has to be performed from the main app. this call will perform
+    <function>gst_init</function> has to be called from the main application. 
-    first initialisation and will parse the GStreamer specific command line 
+    This call will perform the necessary initialization of the library as
-    options. 
+    well as parse the GStreamer-specific command line options.
   </para>
   <para> 
     A typical program would start like this:
@@ -28,7 +29,17 @@ main (int argc, char *argv[])
 }
   </programlisting>
   <para>
-    It is also possible to call the gst_init method with two NULL arguments.
+    Use the <symbol>GST_VERSION_MAJOR</symbol>,
+    <symbol>GST_VERSION_MINOR</symbol> and <symbol>GST_VERSION_MICRO</symbol>
+    macros to get the <application>GStreamer</application> version you are
+    building against, or use the function <function>gst_version</function>
+    to get the version your application is linked against.
+<!--    FIXME: include an automatically generated list of these options. -->
+  </para>
+  <para>
+    It is also possible to call the <function>gst_init</function> function
+    with two <symbol>NULL</symbol> arguments, in which case no command line
+    options will parsed by <application>GStreamer</application>.
   </para>
   <para> 
     Use the GST_VERSION_MAJOR, GST_VERSION_MINOR and GST_VERSION_MICRO macros to
@@ -58,6 +69,15 @@ main(int argc, char *argv[])
 
   ...
     </programlisting>
+    <para>
+      As shown in this fragment, you can use a <ulink
+      url="http://developer.gnome.org/doc/guides/popt/"
+      type="http">popt</ulink> table to define your application-specific
+      command line options, and pass this table to the
+      function <function>gst_init_with_popt_table</function>. Your
+      application options will be parsed in addition to the standard
+      <application>GStreamer</application> options.
+
   </sect1>
 
 </chapter>

docs/manual/intro-motivation.xml

@@ -83,7 +83,8 @@
       </para> 
       <para> 
         No provisions have been made for emerging technologies such as
-	the GNOME object embedding using Bonobo.
+        the <ulink url="http://developer.gnome.org/arch/component/bonobo.html"
+          type="http">GNOME object embedding using Bonobo</ulink>.
       </para> 
       <para> 
         The GStreamer cores does not use network transparent technologies at the

docs/manual/intro-preface.xml

@@ -22,14 +22,14 @@
     </para> 
 
     <para>
-      One of the the most obvious uses of GStreamer is using it to build a media player.
+      One of the the most obvious uses of GStreamer is using it to build
-      GStreamer already includes components for building a media player that can support a
+      a media player.  GStreamer already includes components for building a
-      very wide variety of formats including mp3, Ogg Vorbis, Mpeg1, Mpeg2, Avi, Quicktime, mod
+      media player that can support a very wide variety of formats, including
-      and so on. 
+      mp3, Ogg Vorbis, MPEG1, MPEG2, AVI, Quicktime, mod and so on.  GStreamer,
-      GStreamer, however, is much more than just another media player. Its
+      however, is much more than just another media player. Its main advantages
-      main advantages are that the pluggable components can be mixed and matched into 
+      are that the pluggable components can be mixed and matched into arbitrary
-      abitrary pipelines so that it's possible
+      pipelines so that it's possible to write a full-fledged video or audio
-      to write a full fledged video or audio editing application. 
+      editing application.
     </para> 
 
     <para>

docs/manual/intro.xml

@@ -22,14 +22,14 @@
     </para> 
 
     <para>
-      One of the the most obvious uses of GStreamer is using it to build a media player.
+      One of the the most obvious uses of GStreamer is using it to build
-      GStreamer already includes components for building a media player that can support a
+      a media player.  GStreamer already includes components for building a
-      very wide variety of formats including mp3, Ogg Vorbis, Mpeg1, Mpeg2, Avi, Quicktime, mod
+      media player that can support a very wide variety of formats, including
-      and so on. 
+      mp3, Ogg Vorbis, MPEG1, MPEG2, AVI, Quicktime, mod and so on.  GStreamer,
-      GStreamer, however, is much more than just another media player. Its
+      however, is much more than just another media player. Its main advantages
-      main advantages are that the pluggable components can be mixed and matched into 
+      are that the pluggable components can be mixed and matched into arbitrary
-      abitrary pipelines so that it's possible
+      pipelines so that it's possible to write a full-fledged video or audio
-      to write a full fledged video or audio editing application. 
+      editing application.
     </para> 
 
     <para>

docs/manual/motivation.xml

@@ -83,7 +83,8 @@
       </para> 
       <para> 
         No provisions have been made for emerging technologies such as
-	the GNOME object embedding using Bonobo.
+        the <ulink url="http://developer.gnome.org/arch/component/bonobo.html"
+          type="http">GNOME object embedding using Bonobo</ulink>.
       </para> 
       <para> 
         The GStreamer cores does not use network transparent technologies at the

docs/manual/plugins.xml

@@ -1,23 +1,25 @@
 <chapter id="cha-plugins">
-  <title>What are Plugins</title>
+  <title>Plugins</title>
+  <!-- FIXME: introduce type definitions before this chapter -->
   <para> 
-    A plugin is a shared library that contains at least one of the following items:
+    A plugin is a shared library that contains at least one of the following
+    items:
   </para>
 
   <itemizedlist>
     <listitem>
       <para>
-        one or more elementfactories
+        one or more element factories
       </para>
     </listitem>
     <listitem>
       <para>
-        one or more typedefinitions
+        one or more type definitions
       </para>
     </listitem>
     <listitem>
       <para>
-        one or more autopluggers
+        one or more auto-pluggers
       </para>
     </listitem>
     <listitem>
@@ -27,19 +29,24 @@
     </listitem>
   </itemizedlist>
   <para> 
-    The plugins have one simple method: plugin_init () where all the elementfactories are
+    All plugins should implement one function, <function>plugin_init</function>,
-    created and the typedefinitions are registered.
+    that creates all the element factories and registers all the type
+    definitions contained in the plugin.
+    Without this function, a plugin cannot be registered.
   </para> 
   <para> 
-    the plugins are maintained in the plugin system. Optionally, the typedefinitions and 
+    The plugins are maintained in the plugin system. Optionally, the
-    the elementfactories can be saved into an XML representation so that the plugin system
+    type definitions and the element factories can be saved into an XML
-    does not have to load all available plugins in order to know their definition.
+    representation so that the plugin system does not have to load all
+    available plugins in order to know their definition.
   </para> 
 														  
   <para> 
     The basic plugin structure has the following fields:
   </para> 
   <programlisting>
+typedef struct _GstPlugin   GstPlugin;
+
 struct _GstPlugin {
   gchar *name;                  /* name of the plugin */
   gchar *longname;              /* long name of plugin */
@@ -57,7 +64,8 @@ struct _GstPlugin {
   </programlisting>
 
   <para> 
-    You can query a GList of available plugins with:
+    You can query a <classname>GList</classname> of available plugins with the
+    function <function>gst_plugin_get_list</function> as this example shows:
   </para> 
   <programlisting>
     GList *plugins;

docs/manual/threads.xml

@@ -81,7 +81,7 @@
 
 /* eos will be called when the src element has an end of stream */
 void 
-eos (GstSrc *src, gpointer data) 
+eos (GstElement *src, gpointer data) 
 {
   GstThread *thread = GST_THREAD (data);
   g_print ("have eos, quitting\n");