Spelling/grammar fixes from Martin Buchholz <martin@xemacs.org>

Tue Feb 29 13:10:00 GMT 2000  Tony Gale <gale@gtk.org>

        * gdk/gdkwindow.h gdk/x11/gxid.c gtk/gtkclist.c gtk/gtkclist.h
          gtk/gtkctree.c gtk/gtkmenu.h gtk/gtkwidget.c gtk/testgtk.c
          docs/styles.txt docs/refcounting.txt docs/gtkfaq.sgml
          docs/gtk_tut.sgml docs/gtk.texi TODO:
          Spelling/grammar fixes from Martin Buchholz <martin@xemacs.org>

7 files changed, 21 insertions, 21 deletions

diff --git a/docs/faq/gtkfaq.sgml b/docs/faq/gtkfaq.sgml
index 89693940e0..8b5f840915 100644
--- a/docs/faq/gtkfaq.sgml
+++ b/docs/faq/gtkfaq.sgml
@@ -741,7 +741,7 @@ are:
 You'll find these packages on the GNU main ftp server (<htmlurl 
 url="ftp://ftp.gnu.org/" name="ftp://ftp.gnu.org/">) or on any GNU mirror.
 
-In order to use the powerfull autoconf/automake scheme, you must create
+In order to use the powerful autoconf/automake scheme, you must create
 a configure.in which may look like:
 
 <tscreen><verb>
@@ -1521,7 +1521,7 @@ performance penalty.
 Its possible that, in the long term, the best solution to such
 problems might be just to change gtk to give labels X windows.
 A short term workaround is to put the label widget inside another
-widget that does get it's own window - one possible candidate would
+widget that does get its own window - one possible candidate would
 be the viewport widget.
 
 <tscreen><verb>
@@ -1576,7 +1576,7 @@ carefully.
 
 There are two (easy) ways to attach some data to a gtk object. 
 Using <tt/gtk_object_set_data()/ and <tt/gtk_object_get_data()/ seems to be the 
-most common way to do this, as it provides a powerfull interface 
+most common way to do this, as it provides a powerful interface 
 to connect objects and data.
 
 <tscreen><verb>
@@ -2594,7 +2594,7 @@ main (int argc, char *argv[])
   /* give the error handler an idea on how the input is named */
   scanner->input_name = "test text";
 
-  /* scanning loop, we parse the input untill it's end is reached,
+  /* scanning loop, we parse the input until its end is reached,
    * the scanner encountered a lexing error, or our sub routine came
    * across invalid syntax
    */
@@ -2624,7 +2624,7 @@ main (int argc, char *argv[])
 }
 </verb>
 
-You need to understand that the scanner will parse it's input and
+You need to understand that the scanner will parse its input and
 tokenize it, it is up to you to interpret these tokens, not define
 their types before they get parsed, e.g. watch gscanner parse a string:
  
diff --git a/docs/gtk.texi b/docs/gtk.texi
index 6f1abfe586..46b74f2cc9 100644
--- a/docs/gtk.texi
+++ b/docs/gtk.texi
@@ -79,7 +79,7 @@ approved by Peter Mattis.
 This is edition @value{edition} of the GTK documentation,
 @w{@value{update-date}}.
 @end ifinfo
-@c FIXME: Do a introduction to the GTK?
+@c FIXME: Do an introduction to the GTK?
 
 @menu
 * Copying::                     Your rights.
@@ -288,7 +288,7 @@ form that is easier to parse.  Tools for generating bindings of Gtk to
 other languages can read these declarations and---because all the
 important details are defined---automatically generate the bulk of the
 needed glue code.  It is also possible to feed these declarations into a
-running application (a interface builder, say) and thus make it aware of
+running application (an interface builder, say) and thus make it aware of
 new widgets and functions without recompiling anything.
 
 The run-time side of the type system is also somewhat introspective.
@@ -320,7 +320,7 @@ inherit these rules from their fundamental type.  For example,
 derive from @samp{GtkObject} and so the rules for @samp{GtkObject} apply
 to all widgets as well.
 
-This derivation defines a type hierachy, but this hierachy is not
+This derivation defines a type hierarchy, but this hierachy is not
 completely general.  You can't derive from @samp{int} for example, and
 you can only have one level of derivation from @samp{enum}.  The
 fundamental type @samp{GtkObject}, however, is the basis for the large
@@ -382,7 +382,7 @@ to a fundamental type and thus there is no name for it.
 
 @deftp {Data type} GtkType
 The type @code{GtkType} holds the run-time representation of a type.  It
-is a integer of a certain size.  The follwing macros are defined to
+is an integer of a certain size.  The follwing macros are defined to
 access the basic properties of a @code{GtkType}:
 
 @deftypefn {Macro} {unsigned int} GTK_TYPE_SEQNO (GtkType type)
@@ -461,7 +461,7 @@ always return @code{NULL}.
 @item
 The @code{class_init_func} and @code{base_class_init_func} fields are
 callbacks which are used by the type mechanism to initialize class
-specific fields. The single argument these function taks is a pointer to
+specific fields. The single argument these functions take is a pointer to
 a class structure.  When you do not need one or both of them, set the
 corresponding field to @code{NULL}.  The @code{class_init_func} will be
 called at most once, right after the class structure of size
diff --git a/docs/gtk_tut.sgml b/docs/gtk_tut.sgml
index e2fc98ad7e..4e09af0554 100644
--- a/docs/gtk_tut.sgml
+++ b/docs/gtk_tut.sgml
@@ -6654,7 +6654,7 @@ the <ref id="sec_ProgressBar" name="Progress Bar"> widget.
 <sect1> Fixed Container
 <p>
 The Fixed container allows you to place widgets at a fixed position
-within it's window, relative to it's upper left hand corner. The
+within its window, relative to its upper left hand corner. The
 position of the widgets can be changed dynamically.
 
 There are only three functions associated with the fixed widget:
diff --git a/docs/gtkfaq.sgml b/docs/gtkfaq.sgml
index 89693940e0..8b5f840915 100644
--- a/docs/gtkfaq.sgml
+++ b/docs/gtkfaq.sgml
@@ -741,7 +741,7 @@ are:
 You'll find these packages on the GNU main ftp server (<htmlurl 
 url="ftp://ftp.gnu.org/" name="ftp://ftp.gnu.org/">) or on any GNU mirror.
 
-In order to use the powerfull autoconf/automake scheme, you must create
+In order to use the powerful autoconf/automake scheme, you must create
 a configure.in which may look like:
 
 <tscreen><verb>
@@ -1521,7 +1521,7 @@ performance penalty.
 Its possible that, in the long term, the best solution to such
 problems might be just to change gtk to give labels X windows.
 A short term workaround is to put the label widget inside another
-widget that does get it's own window - one possible candidate would
+widget that does get its own window - one possible candidate would
 be the viewport widget.
 
 <tscreen><verb>
@@ -1576,7 +1576,7 @@ carefully.
 
 There are two (easy) ways to attach some data to a gtk object. 
 Using <tt/gtk_object_set_data()/ and <tt/gtk_object_get_data()/ seems to be the 
-most common way to do this, as it provides a powerfull interface 
+most common way to do this, as it provides a powerful interface 
 to connect objects and data.
 
 <tscreen><verb>
@@ -2594,7 +2594,7 @@ main (int argc, char *argv[])
   /* give the error handler an idea on how the input is named */
   scanner->input_name = "test text";
 
-  /* scanning loop, we parse the input untill it's end is reached,
+  /* scanning loop, we parse the input until its end is reached,
    * the scanner encountered a lexing error, or our sub routine came
    * across invalid syntax
    */
@@ -2624,7 +2624,7 @@ main (int argc, char *argv[])
 }
 </verb>
 
-You need to understand that the scanner will parse it's input and
+You need to understand that the scanner will parse its input and
 tokenize it, it is up to you to interpret these tokens, not define
 their types before they get parsed, e.g. watch gscanner parse a string:
  
diff --git a/docs/refcounting.txt b/docs/refcounting.txt
index 61a161d39f..0c9de31336 100644
--- a/docs/refcounting.txt
+++ b/docs/refcounting.txt
@@ -15,7 +15,7 @@ functions that follow these conventions:
 GtkObjects also provide the following functions:
 
   *_destroy:  Render an object `unusable', but as long as there are
-              references to it, it's allocated memory will not be freed.
+              references to it, its allocated memory will not be freed.
   *_sink:     Clear a GtkObjects `floating' state and decrement the
 	      reference count by 1.
 
@@ -248,7 +248,7 @@ widget, it needs to hold a reference to it.
 Example code sequences that require reference wraps:
 
    /* gtk_container_remove() will unparent the child and therefore
-    * cause it's reference count to be decremented by one.
+    * cause its reference count to be decremented by one.
     */
    gtk_widget_ref (widget);
    gtk_container_remove (container, widget);
diff --git a/docs/styles.txt b/docs/styles.txt
index e66cafd19a..a3f31c9456 100644
--- a/docs/styles.txt
+++ b/docs/styles.txt
@@ -88,13 +88,13 @@ GtkWidget::style_set
 Flag indications:
 
 !GTK_RC_STYLE && !GTK_USER_STYLE:
-  The widget has it's default style set, no rc lookup has been
+  The widget has its default style set, no rc lookup has been
   performed, the widget has not been size requested yet and is
   therefore not yet realized.
 
 GTK_USER_STYLE:
   GTK_RC_STYLE is not set.
-  The widget has a user style assigned, and it's default style has been
+  The widget has a user style assigned, and its default style has been
   saved.
 
 GTK_RC_STYLE:
diff --git a/docs/tutorial/gtk_tut.sgml b/docs/tutorial/gtk_tut.sgml
index e2fc98ad7e..4e09af0554 100644
--- a/docs/tutorial/gtk_tut.sgml
+++ b/docs/tutorial/gtk_tut.sgml
@@ -6654,7 +6654,7 @@ the <ref id="sec_ProgressBar" name="Progress Bar"> widget.
 <sect1> Fixed Container
 <p>
 The Fixed container allows you to place widgets at a fixed position
-within it's window, relative to it's upper left hand corner. The
+within its window, relative to its upper left hand corner. The
 position of the widgets can be changed dynamically.
 
 There are only three functions associated with the fixed widget: