[gst-cvs] thomasvs gstreamer: gstreamer/docs/pwg/

[<tho...@fr...>]

CVS Root:       /cvs/gstreamer
Module:         gstreamer
Changes by:     thomasvs
Date:           Thu Nov 25 2004  07:45:48 PST

Log message:
fix some typos

Modified files:
    docs/pwg        : advanced-interfaces.xml

Links:
http://freedesktop.org/cgi-bin/viewcvs.cgi/gstreamer/gstreamer/docs/pwg/advanced-interfaces.xml.diff?r1=1.9&r2=1.10

====Begin Diffs====
Index: advanced-interfaces.xml
===================================================================
RCS file: /cvs/gstreamer/gstreamer/docs/pwg/advanced-interfaces.xml,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -d -r1.9 -r1.10
--- advanced-interfaces.xml	27 Jul 2004 15:01:10 -0000	1.9
+++ advanced-interfaces.xml	25 Nov 2004 15:45:36 -0000	1.10
@@ -3,26 +3,26 @@
   <para>
     Previously, in the chapter <xref linkend="chapter-building-args"/>, we have
     introduced the concept of GObject properties of controlling an element's
-    behaviour. This is a very powerful, but has two big disadvantage: firstly,
-    it is too generic, and secondly, it isn't dynamic.
+    behaviour. This is very powerful, but it has two big disadvantages:
+    first of all, it is too generic, and second, it isn't dynamic.
   </para>
-    The first disadvantage has to do with customizability of the end-user
+    The first disadvantage is related to the customizability of the end-user
     interface that will be built to control the element. Some properties are
     more important than others. Some integer properties are better shown in a
     spin-button widget, whereas others would be better represented by a slider
     widget. Such things are not possible because the UI has no actual meaning
-    in the application. A UI widget that stands for a bitrate property is the
-    same as an UI widget that stands for the size of a video, as long as both
+    in the application. A UI widget that represents a bitrate property is the
+    same as a UI widget that represents the size of a video, as long as both
     are of the same <classname>GParamSpec</classname> type. Another problem,
-    related to the one about parameter important, is that things like parameter
-    grouping, function grouping or anything to make parameters coherent, is not
+    is that things like parameter grouping, function grouping, or parameter
+    coupling are not
     really possible.
-    The second argument against parameters are that they are not dynamic. In
+    The second problem with parameters are that they are not dynamic. In
     many cases, the allowed values for a property are not fixed, but depend
-    on things that can only be detected at run-time. The names of inputs for
+    on things that can only be detected at runtime. The names of inputs for
     a TV card in a video4linux source element, for example, can only be
     retrieved from the kernel driver when we've opened the device; this only
     happens when the element goes into the READY state. This means that we
@@ -44,8 +44,9 @@
     One important note: interfaces do <emphasis>not</emphasis> replace
     properties. Rather, interfaces should be built <emphasis>next to</emphasis>
-    properties. There are two important reasons for this. Firstly, properties
-    can be saved in XML files. Secondly, properties can be specified on the
+    properties. There are two important reasons for this. First of all, 
+    properties
+    can be saved in XML files. Second, properties can be specified on the
     commandline (<filename>gst-launch</filename>).