Apply a cleanup patch by Kjartan Maraas (#341812)

2006-10-08  Matthias Clasen  <mclasen@redhat.com>

	* Apply a cleanup patch by Kjartan Maraas  (#341812)

12 files changed, 51 insertions, 51 deletions

diff --git a/docs/README.linux-fb b/docs/README.linux-fb
index 3cb1b1eae6..ef113785a9 100644
--- a/docs/README.linux-fb
+++ b/docs/README.linux-fb
@@ -32,7 +32,7 @@ Freetype can be found at ftp://ftp.freetype.org
 
 Hardware requirements:
 ----------------------
-You need a graphics card with an availible framebuffer driver that can
+You need a graphics card with an available framebuffer driver that can
 run in 8, 16, 24 or 32 bpp. I use the matroxfb driver, but i.e. vesafb
 should work too. You also need a supported mouse. Currently supported
 is ps2 mouse, ms serial mouse and fidmour touchscreen.
@@ -44,7 +44,7 @@ First build and install glib and pango as usual, in that order.
 Then configure Gtk by running configure (or autogen.sh if running from
 cvs) with --with-gdktarget=linux-fb.
 
-Then compile as ususal: make; make install
+Then compile as usual: make; make install
 
 Fonts:
 ------
@@ -124,7 +124,7 @@ GDK_MOUSE_TYPE:
  Default is ps2.
 
 GDK_KEYBOARD_TYPE:
- Specify keyboard type. Currently suppored is
+ Specify keyboard type. Currently supported is
   xlate - normal tty mode keyboard.
     Quite limited, cannot detect key up/key down events. Doesn't
     handle ctrl/alt/shift for all keys. This is the default driver,
diff --git a/docs/developers.txt b/docs/developers.txt
index ee78bea4f8..e50c8ca1ff 100644
--- a/docs/developers.txt
+++ b/docs/developers.txt
@@ -6,7 +6,7 @@ programming for/with Gtk, having the spirit of a developers FAQ.
 It is also the correct place to list up things that programmers should
 care about in general.
 
-In the hope that this text might be usefull to someone,
+In the hope that this text might be useful to someone,
 
         - Tim Janik <timj@gimp.org>
           1998/02/11
@@ -43,7 +43,7 @@ GDK_SELECTION_CLEAR     GtkWidget::selection_clear_event
 GDK_FOCUS_CHANGE        GtkWidget::focus_in_event
                         GtkWidget::focus_out_event
 
-Events that are asured to have a valid GdkEvent.any.window field are
+Events that are assured to have a valid GdkEvent.any.window field are
 
 GDK_EXPOSE		GtkWidget::expose_event
 
@@ -61,7 +61,7 @@ Writing Gdk functions
 ---------------------
 
 When writing Gdk functions that operate on GdkWindow structures in any
-maeningfull sense, that is casting to a GdkWindowPrivate structure for
+meaningful sense, that is casting to a GdkWindowPrivate structure for
 access to fields other then GdkWindow.user_data, the programmer is
 recommended to check for the GdkWindowPrivate.destroyed field to be ==
 FALSE, especially if the GdkWindowPrivate.xwindow field is used.
diff --git a/docs/dnd_internals.txt b/docs/dnd_internals.txt
index 46156dfdd9..62312ef0fa 100644
--- a/docs/dnd_internals.txt
+++ b/docs/dnd_internals.txt
@@ -112,7 +112,7 @@ Retrieves the selection that will be used to communicate
 the data for the drag context (valid on both source
 and dest sides)
 
-Cursors and window heirarchies
+Cursors and window hierarchies
 ==============================
 
 The DND code, when possible (and it isn't possible over
@@ -123,7 +123,7 @@ the cursor is in _ourselves_ so we can ignore the
 drag icon properly. (Oh for OutputOnly windows!)
 
 To avoid obscene amounts of server traffic (which are only
-slighly observerable locally, but would really kill a
+slightly observable locally, but would really kill a
 session over a slow link), the code in GDK does
 XGetWindowAttributes for every child of the root window at
 the beginning of the drag, then selects with
diff --git a/docs/faq/gtk-faq.sgml b/docs/faq/gtk-faq.sgml
index b06dbcd834..03705309e1 100644
--- a/docs/faq/gtk-faq.sgml
+++ b/docs/faq/gtk-faq.sgml
@@ -1636,7 +1636,7 @@ int main(int argc, char *argv[])
   gtk_container_set_border_width(GTK_CONTAINER (window), 10);
 #endif
 
-  /* add a button to do something usefull */
+  /* add a button to do something useful */
   button = gtk_button_new_with_label("Fork me!");
           
   g_signal_connect(G_OBJECT (button), "clicked",
diff --git a/docs/faq/gtkfaq.sgml b/docs/faq/gtkfaq.sgml
index 198263fc04..bc914ae0c0 100644
--- a/docs/faq/gtkfaq.sgml
+++ b/docs/faq/gtkfaq.sgml
@@ -1323,7 +1323,7 @@ int main(int argc, char *argv[])
   gtk_container_set_border_width(GTK_CONTAINER (window), 10);
 #endif
 
-  /* add a button to do something usefull */
+  /* add a button to do something useful */
   button = gtk_button_new_with_label("Fork me!");
           
   gtk_signal_connect(GTK_OBJECT (button), "clicked",
diff --git a/docs/focus_tracking.txt b/docs/focus_tracking.txt
index c0fcf08a4f..f3576c180c 100644
--- a/docs/focus_tracking.txt
+++ b/docs/focus_tracking.txt
@@ -97,7 +97,7 @@ F2, F3: together these are exactly the cases where we get
 
 F4: we get an LeaveNotify with the focus flag set. An
   LeaveNotify with a focus flag set will also be sent if 
-  F==W, so we have to to explicity test for that case
+  F==W, so we have to to explicitly test for that case
   using has_focus_window(W).
 
 
diff --git a/docs/generation.txt b/docs/generation.txt
index 5ec2d83bea..bc47664cdf 100644
--- a/docs/generation.txt
+++ b/docs/generation.txt
@@ -107,7 +107,7 @@ makeenums.pl can be run into two modes:
 
  2) Generate the enumeration portion of gtk.defs.
 
-The enumearation portion is added to the boxed type 
+The enumeration portion is added to the boxed type 
 declarations in gtk-boxed.defs to create gtk.defs.
 
 The makeetypes.awk program takes the gtk.defs file, and
@@ -162,7 +162,7 @@ The possible types are:
 	     GtkDestroyNotify Notify)
 
 Some of these types map to multiple return values - these
-are marked above with the return types in parantheses.
+are marked above with the return types in parentheses.
 
 NOTES
 =====
@@ -170,7 +170,7 @@ NOTES
 When autogenerating GTK+ files, the autogenerated
 files are often rebuild resulting in the same result.
 
-To prevent unecessary rebuilds of the entire directory, some files
+To prevent unnecessary rebuilds of the entire directory, some files
 that multiple other source files depend on are not actually written
 to directly.  Instead, an intermediate file is written, which
 is then compared to the old file, and only if it is different
diff --git a/docs/gtk-config.txt b/docs/gtk-config.txt
index c82b8d0c9b..f168ec715d 100644
--- a/docs/gtk-config.txt
+++ b/docs/gtk-config.txt
@@ -1,7 +1,7 @@
 CONFIGURING PACKAGES TO WORK WITH GTK
 -------------------------------------
 
-Compiling a program succesfully against the GTK, GDK, and GLIB
+Compiling a program successfully against the GTK, GDK, and GLIB
 libraries can require a large number of command line options
 to your compiler and linker that are hard to guess correctly.
 The additional libraries required may, for example, depend on the
diff --git a/docs/refcounting.txt b/docs/refcounting.txt
index 0c9de31336..f8b62ed5e3 100644
--- a/docs/refcounting.txt
+++ b/docs/refcounting.txt
@@ -22,10 +22,10 @@ GtkObjects also provide the following functions:
 GdkWindow
 ---------
 
-A GdkWindow has to be explicitely destroyed with gdk_window_destroy.
+A GdkWindow has to be explicitly destroyed with gdk_window_destroy.
 This will send out a request to destroy this window and all its
 children, and will decrement the ref_count of the GdkWindow by one.
-Thus, it releases the inital reference created by gdk_window_new.
+Thus, it releases the initial reference created by gdk_window_new.
 
 All GdkWindows are kept in a hash table to translate from their XId to
 the actual structure and the pointer in the hash table is reflected in
@@ -62,7 +62,7 @@ GdkVisual
 ---------
 
 There are no *_new or *_destroy functions and the *_ref and *_unref
-functions are noops.  GdkVisuals are static structures and thus do not
+functions are no-ops.  GdkVisuals are static structures and thus do not
 need reference counting.  The ref counting functions are only there
 for extra defensive programming.
 
@@ -220,13 +220,13 @@ Then, when the user wants to get rid of the window:
   /* The GdkWindow of `window' and all its child GdkWindows are
    * destroyed.
    *
-   * window is unregistered from the loplevel list and its ref_count
-   * drops to zero.  The destroy code of `window' destroyes `option_menu'.
+   * window is unregistered from the toplevel list and its ref_count
+   * drops to zero.  The destroy code of `window' destroys `option_menu'.
    *
    * The destroy code of `option_menu' causes the `menu' to be detached
    * from it and its reference count drops to zero.
    *
-   * The destroy code of `menu' destroyes `menu_item'.
+   * The destroy code of `menu' destroys `menu_item'.
    *
    * The destruction of `menu_item' removes it from its parent, the
    * menu_item->ref_count drops to zero and `menu_item' is finalized (freed).
@@ -241,7 +241,7 @@ Taking care of proper referencing
 
 There are some cases where referencing of widgets from outside the toolkit
 (on the application side) is needed.
-Once the application performes an operation on a widget that will cause
+Once the application performs an operation on a widget that will cause
 its reference count to drop, if it wants to take further actions on the
 widget, it needs to hold a reference to it.
 
diff --git a/docs/styles.txt b/docs/styles.txt
index a3f31c9456..a081d3cdf4 100644
--- a/docs/styles.txt
+++ b/docs/styles.txt
@@ -26,11 +26,11 @@ gtk_widget_set_rc_style ()
   This will override a previously set user style or rc style.
 
 gtk_widget_reset_rc_styles ()
-  Descends through a widget heirarchy and sets the rc style
+  Descends through a widget hierarchy and sets the rc style
   on all widgets that don't have a user style set.
 
 gtk_widget_restore_default_style ()
-  Reset the widget's style to the default style, this is only usefull if
+  Reset the widget's style to the default style, this is only useful if
   the widgets default style had been saved by previous calls to
   gtk_widget_set_style() or gtk_widget_set_rc_style().
 
@@ -47,12 +47,12 @@ gtk_widget_set_name ()
 
 gtk_widget_realize ()
   Besides realizing the widget this function will:
-  - perform an rc lookup if neccessary,
+  - perform an rc lookup if necessary,
   - attach a widget's style.
 
 gtk_widget_get_style ()
   Return a widgets style, this function will perform an rc lookup
-  if neccessary.
+  if necessary.
 
 gtk_widget_set_parent ()
   This function will perform rc lookups recursively for all widgets
@@ -60,22 +60,22 @@ gtk_widget_set_parent ()
 
 gtk_style_copy ()
   This function can be used to copy a widget's style.
-  The style can subsequntly be changed (e.g., by modifications to the
+  The style can subsequently be changed (e.g., by modifications to the
   red/green/blue values of a certain color) and then be applied to the
   widget via gtk_widget_set_style().
 
 
 GtkWidget::style_set
   This signal will be emitted for a widget once its style changes with
-  an additional argument previous_style wich will hold the widget->style
-  avlue from a previous emission.
+  an additional argument previous_style which will hold the widget->style
+  value from a previous emission.
   The initial emission of this signal is guaranteed to happen prior
   to any GtkWidget::size_request emission, and will have the previous_style
   argument set to NULL.
   The GtkWidgetClass implements a default handler for this signal that
   will set the widget's window's background of widgets that provide their
   own windows according to the new style.
-  Derived widgets need to overide this default handler, if:
+  Derived widgets need to override this default handler, if:
   - their size requisition depends on the current style.
     (e.g., on the style's fonts)
   - they set the background of widget->window to something other than.
diff --git a/docs/text_widget.txt b/docs/text_widget.txt
index 62ca6ba55b..55b675eabc 100644
--- a/docs/text_widget.txt
+++ b/docs/text_widget.txt
@@ -18,7 +18,7 @@ complicated data structure exercise).  I'm happy to answer questions.
 High level description:
 
 There are several layers of data structure to the widget.  They are
-seperated from each other as much as possible.  The first is a gapped
+separated from each other as much as possible.  The first is a gapped
 text segment similar to the data structure Emacs uses for representing
 text.  Then there is a property list, which stores text properties for
 various ranges of text.  There is no direct relation between the text
@@ -93,7 +93,7 @@ transition.  An important point is that all property marks are invalid
 after a buffer modification unless care is taken to keep them
 accurate.  That is the difficulty of the insert and delete operations,
 because as the next section describes, line data is cached and by
-neccesity contains text property marks.  The functions for operating
+necessity contains text property marks.  The functions for operating
 and computing property marks are:
 
  void advance_mark     (GtkPropertyMark* mark);
@@ -117,8 +117,8 @@ of the file for doing things like getting the current text property,
 or some component of the current property.  See the MARK_* macros.
 
 Next there is a LineParams structure which contains all the
-information neccesary to draw one line of text on screen.  When I say
-"line" here, I do not mean one line of text seperated by newlines,
+information necessary to draw one line of text on screen.  When I say
+"line" here, I do not mean one line of text separated by newlines,
 rather I mean one row of text on screen.  It is a matter of policy how
 visible lines are chosen and there are currently two policies,
 line-wrap and no-line-wrap.  I suspect it would not be difficult to
@@ -167,7 +167,7 @@ often, the last index is treated as a newline.
   is, its properties are always that of the preceding character,
   if any.
   
-  There is a fair bit of special case code to mantain this condition -
+  There is a fair bit of special case code to maintain this condition -
   which is needed so that user has control over the properties of
   characters inserted at the last position. OWT 2/9/98 ]
 
@@ -268,7 +268,7 @@ visible lines:
   guint first_onscreen_ver_pixel;
 
 LINE_START_CACHE is a doubly linked list of LineParams.  CURRENT_LINE
-is a transient piece of data which is set in varoius places such as
+is a transient piece of data which is set in various places such as
 the mouse click code.  Generally, it is the line on which the cursor
 property mark CURSOR_MARK is on.  LINE_START_CACHE points to the first
 visible line and may contain PREV pointers if the cached data of
@@ -331,7 +331,7 @@ The text properties list:
   GList *text_properties_end;
 
 A scratch area used for constructing a contiguous piece of the buffer
-which may otherwise span the gap.  It is not strictly neccesary
+which may otherwise span the gap.  It is not strictly necessary
 but simplifies the drawing code because it does not need to deal with
 the gap.
 
@@ -408,7 +408,7 @@ copy area call.  If the CURSOR argument to EXPOSE_TEXT is true, it
 also draws the cursor.
 
 The function DRAW_LINE draws a single line, doing all the tab and
-color computations neccesary.  The function DRAW_LINE_WRAP draws the
+color computations necessary.  The function DRAW_LINE_WRAP draws the
 line wrap bitmap at the end of the line if it wraps.  TEXT_EXPOSE will
 expand the cached line data list if it has to by calling
 FETCH_LINES_FORWARD.  The functions DRAW_CURSOR and UNDRAW_CURSOR draw
@@ -427,12 +427,12 @@ RECOMPUTE_GEOMETRY is called when the geometry of the window changes
 or when it is first drawn.  This is probably not done right.  My
 biggest weakness in writing this code is that I've never written a
 widget before so I got most of the event handling stuff wrong as far
-as Gtk is concerned.  Fortunatly, most of the code is unrelated and
+as Gtk is concerned.  Fortunately, most of the code is unrelated and
 simply an exercise in data structure manipulation.
 
 Scrolling:
 
-Scrolling is fairly straighforward.  It looks at the top line, and
+Scrolling is fairly straightforward.  It looks at the top line, and
 advances it pixel by pixel until the FIRST_CUT_PIXELS equals the line
 height and then advances the LINE_START_CACHE.  When it runs out of
 lines it fetches more.  The function SCROLL_INT is used to scroll from
@@ -454,7 +454,7 @@ character.  It's fairly complicated.  In order to do efficient pasting
 into the buffer, or write code that modifies the buffer while the
 buffer is drawn, it needs to do multiple characters at at time.  This
 is the hardest part of what remains.  Currently, gtk_text_insert does
-not reexpose the modified lines.  It needs to.  Pete did this wrong at
+not re-expose the modified lines.  It needs to.  Pete did this wrong at
 one point and I disabled modification completely, I don't know what
 the current state of things are.  The functions
 INSERT_CHAR_LINE_EXPOSE and DELETE_CHAR_LINE_EXPOSE do the work.
@@ -477,7 +477,7 @@ Here's pseudo code for insert.  Delete is quite similar.
 
 What needs to be done:
 
-Horizintal scrolling, robustness, testing, selection handling.  If you
+Horizontal scrolling, robustness, testing, selection handling.  If you
 want to work in the text widget pay attention to the debugging
 facilities I've written at the end of gtktext.c.  I'm sorry I waited
 so long to try and pass this off.  I'm super busy with school and
diff --git a/docs/widget_system.txt b/docs/widget_system.txt
index eb7dce32d2..e60ac32d8d 100644
--- a/docs/widget_system.txt
+++ b/docs/widget_system.txt
@@ -45,7 +45,7 @@ GtkObject:
 GTK_DESTROYED:
 	This flagged is set for a GtkObject right before its
 	destruction code is executed. Its main use is the
-	prevention of multiple destruction invokations.
+	prevention of multiple destruction invocations.
 	
 GTK_FLOATING:
 	This flag reflects the fact that the holder of the
@@ -94,7 +94,7 @@ GTK_CHILD_VISIBLE
         and visible. Containers like GtkNotebook use this flag.
         A private flag, not a public flag, so if you need to check
         this flag, you should call gtk_widget_get_child_visible().
-        (Should be very rarely necesary.)
+        (Should be very rarely necessary.)
 
 GTK_SENSITIVE:
 	Set and unset by gtk_widget_set_sensitive.
@@ -155,7 +155,7 @@ GtkWidget, private flags:
 GTK_USER_STYLE:
 	A widget is flagged to have a user style, once gtk_widget_set_style
 	has been invoked for it. The use of this flag is to tell widgets
-	wich share a global user style from the ones which got a certain
+	which share a global user style from the ones which got a certain
 	style assign from outside the toolkit.
 	
 GTK_RESIZE_PENDING:
@@ -163,7 +163,7 @@ GTK_RESIZE_PENDING:
 	[some of the code should move to gtkcontainer.c therefore]
 	Relies on GTK_WIDGET_REALIZED(widget)
 	[this is not really enforced throughout the code, but should
-	 be. it only requires a few checks for GTK_WIDGET_RELIZED and
+	 be. it only requires a few checks for GTK_WIDGET_REALIZED and
 	 minor changes to gtk_widget_unrealize, we can then remove the check
 	 in gtk_widget_real_destroy]
 	Means: there is an idle handler waiting for the container to
@@ -176,7 +176,7 @@ GTK_RESIZE_NEEDED:
 	 can be avoided]
 	Means: a widget has been added to the resize_widgets list of
 	its _toplevel_ container (keep this in mind for GtkViewport).
-	Remark: this flag is also used internaly by gtkwindow.c during
+	Remark: this flag is also used internally by gtkwindow.c during
 	the evaluation of resizing worthy widgets.
 
 GTK_LEAVE_PENDING:
@@ -200,7 +200,7 @@ GTK_NEED_REQUEST:
 	requisition. If this flag is set, we must actually emit ::size-request
         when gtk_widget_size_request() is called. Otherwise, we can
         simply widget->requisition. We keep track of this all the time
-        howevever, widgets with this flag set are only added to the resize 
+        however, widgets with this flag set are only added to the resize 
 	queue if they are viewable.
 
 GTK_NEED_ALLOCATION:
@@ -291,7 +291,7 @@ gtk_widget_destroy:
 
 gtk_widget_realize:
  if !GTK_DESTROYED sets GTK_REALIZED
-- Calling gtk_widget_realize when the widget is not a descendent
+- Calling gtk_widget_realize when the widget is not a descendant
   of a toplevel is an ERROR.
 
 gtk_container_add (container, widget) [ and container-specific variants ]
@@ -358,7 +358,7 @@ Widgets are created in an unrealized state.
 The Realize signal
 ------------------
 
-When a widget recieves the "realize" signal it should:
+When a widget receives the "realize" signal it should:
 
  NO_WINDOW widgets: (probably OK to use default handler)
 
@@ -454,7 +454,7 @@ When a widget receives the destroy signal, it must:
 
 The "destroy" signal will only be received once. A widget
 will never receive any other signals after the destroy
-signal (but see the sectionalize on "Finalize" below)
+signal (but see the section on "Finalize" below)
 
 The widget must handle calls to all publically accessible
 functions in an innocuous manner even after a "destroy"