docs: Fix assorted typos in legacy documentation

Samsung reported a long list of typos in our legacy docs, this fixes them.

4 files changed, 61 insertions, 61 deletions

diff --git a/doc/ecore_examples.dox b/doc/ecore_examples.dox
index bf25fa3804..64542779d5 100644
--- a/doc/ecore_examples.dox
+++ b/doc/ecore_examples.dox
@@ -1575,7 +1575,7 @@
  * @skip ecore_main_fd_handler_add
  * @until ;
  *
- * If you don't remenber the parameters of @ref ecore_main_fd_handler_add,
+ * If you don't remember the parameters of @ref ecore_main_fd_handler_add,
  * please check its documentation.
  *
  * Now that we have our handler registered we will start the ecore's main loop:
diff --git a/doc/elementary_examples.dox b/doc/elementary_examples.dox
index af37ae2c62..dc7acbab47 100644
--- a/doc/elementary_examples.dox
+++ b/doc/elementary_examples.dox
@@ -617,7 +617,7 @@
  * project's build system, we're assuming they are the canonical ones.
  *
  * After the program starts, elm_app_info_set() will actually run and
- * then you'll see an intrincasy: Elementary does the prefix lookup @b
+ * then you'll see a problem: Elementary does the prefix lookup @b
  * twice. This is so because of the quicklaunch infrastructure in
  * Elementary (@ref Start), which will register a predefined prefix
  * for possible users of the launch schema. We're not hooking into a
@@ -2112,7 +2112,7 @@
  * We'll start this example in the same way
  * @ref map_example_01 "Map Example 1". Adding a map with buttons to control
  * zoom, so if you didn't read it yet, just do it now. Actually there is
- * a change, that we're aligning buttons to the top, since we wan't a
+ * a change, that we're aligning buttons to the top, since we want a
  * vertical control box this time.
  * @dontinclude map_example_03.c
  * @skipline elm_map_add
@@ -2125,8 +2125,8 @@
  * @skipline horizontal_set
  * @until align_set
  *
- * We'll add an entry with a preliminar address, that I know will
- * find a coordinate, to examplify names work. But you can try
+ * We'll add an entry with a preliminary address, that I know will
+ * find a coordinate, to exemplify how names work. But you can try
  * lots of addresses. From city or country names to pubs, or whatever
  * you want. To try is enough to run the example, type the address and
  * press "Route" button. This button will call a function that will
@@ -2220,7 +2220,7 @@
  * We are just adding the diskselector, so as you can see, defaults for it are:
  * @li Only 3 items visible each time.
  * @li Only 3 characters are displayed for labels on side positions.
- * @li The first added item remains centeres, i.e., it's the selected item.
+ * @li The first added item remains centered, i.e., it's the selected item.
  *
  * To add items, we are just appending it on a loop, using function
  * elm_diskselector_item_append(), that will be better explained on
@@ -2307,7 +2307,7 @@
  * The first parameter of elm_diskselector_item_append() is the diskselector
  * object, that we are receiving as data on our callback function.
  * The second one is a label, the string that will be placed in the center
- * of our item. As we don't wan't icons or callback functions, we can
+ * of our item. As we don't want icons or callback functions, we can
  * send NULL as third, fourth and fifth parameters.
  *
  * <b> Appending an item with icon: </b>
@@ -2543,7 +2543,7 @@
  * The first parameter of elm_list_item_prepend() is the list
  * object, that we are receiving as data on our callback function.
  * The second one is a label, the string that will be placed in the center
- * of our item. As we don't wan't icons or callback functions, we can
+ * of our item. As we don't want icons or callback functions, we can
  * send NULL as third, fourth, fifth and sixth parameters.
  *
  * <b> Appending an item: </b>
@@ -3033,7 +3033,7 @@
  * Note that we set on it both icon and label decorations. It's set to
  * list the contents of the @c "/tmp" directory, too, with
  * elm_fileselector_button_path_set(). What follows are checkboxes to
- * exercise some of its API funtions:
+ * exercise some of its API functions:
  * @dontinclude fileselector_button_example.c
  * @skip ck = elm_check_add
  * @until evas_object_show(en)
@@ -3107,7 +3107,7 @@
  * decorations. It's set to exhibit the path of (and list the contents
  * of, when internal file selector is launched) the @c "/tmp"
  * directory, also, with elm_fileselector_entry_path_set(). What
- * follows are checkboxes to exercise some of its API funtions:
+ * follows are checkboxes to exercise some of its API functions:
  * @dontinclude fileselector_entry_example.c
  * @skip ck = elm_check_add
  * @until callback_add(fs_entry
@@ -3370,7 +3370,7 @@
  * and what to do when the layout theme has its size changed. The full source
  * code for this example can be found at @ref layout_example_03_c.
  *
- * In this exmaple we will use another group from the same layout theme file
+ * In this example we will use another group from the same layout theme file
  * used in @ref layout_example_01. Its instantiation and loading happens in the
  * following lines:
  *
@@ -3909,7 +3909,7 @@
  * It will get the last index item selected's data and find the
  * respective index item handle(#Elm_Object_Item) with elm_index_item_find().
  * We need the latter to query the indexing letter string from, with
- * elm_index_item_letter_get(). Next, comes the delition, itself,
+ * elm_index_item_letter_get(). Next, comes the deletion itself,
  * which will also trigger the @c _index_item_del callback function,
  * as said above.
  *
@@ -4450,7 +4450,7 @@
  *
  * We'll begin by showing a few structures used throught the program. First,
  * the application owns data that holds the main window and the main entry
- * where the editting happens. Then, an auxiliar structure we'll use later
+ * where the editting happens. Then, an auxiliary structure we'll use later
  * when inserting icons in our text.
  * @dontinclude entry_example.c
  * @skip typedef
@@ -5451,7 +5451,7 @@
  * controls will exercise most of the slideshow's API functions.
  *
  * We create the slideshow, itself, first, making it @b loop on its
- * image itens, when in slideshow mode:
+ * image items, when in slideshow mode:
  * @dontinclude slideshow_example.c
  * @skip slideshow = elm_slideshow_add
  * @until evas_object_show
@@ -6218,7 +6218,7 @@
  * @skipline }
  * @skipline }
  *
- * Other @c INT type widget implementations may exist, as is exemplifyed
+ * Other @c INT type widget implementations may exist, as is exemplified
  * on the item that follows.
  *
  * @skip item {
@@ -6877,4 +6877,4 @@
  * @image latex screenshots/combobox_example_01.eps width=\textwidth
  *
  * @example combobox_example_01.c
- */
\ No newline at end of file
+ */
diff --git a/doc/elementary_examples_cxx.dox b/doc/elementary_examples_cxx.dox
index 7b45ed9ff4..6197450ac1 100644
--- a/doc/elementary_examples_cxx.dox
+++ b/doc/elementary_examples_cxx.dox
@@ -60,7 +60,7 @@
  
  * With this tutorial we'll give you a better view of how the lambda
  * function can and will be constantly use in the C++ bindings. For a
- * more broad aproach you should do a little web research.
+ * more broad approach you should do a little web research.
  
  * The syntax adopted for these examples:
  
@@ -200,7 +200,7 @@
  * @until elm_policy_set
  
  * As you can see, the policy we chose was to quit when the last win
- * is hidden as opose to examples with the C bindings where we
+ * is hidden as opposed to examples with the C bindings where we
  * perpetually set it to quit when last win was closed. This changed
  * was necessary because in C++ binding as the elm mainloop stop
  * running all object are destroyed, references are unreferenced and
@@ -323,7 +323,7 @@
  * @until elm_policy_set
 
  * As you can see, the policy we chose was to quit when the last win
- * is hidden as opose to examples with the C bindings where we
+ * is hidden as opposed to examples with the C bindings where we
  * perpetually set it to quit when last win was closed. This changed
  * was necessary because in C++ binding as the elm mainloop stop
  * running all object are destroyed, references are unreferenced and
@@ -488,7 +488,7 @@
  * @until elm_policy_set
  
  * As you can see, the policy we chose was to quit when the last win
- * is hidden as opose to examples with the C bindings where we
+ * is hidden as opposed to examples with the C bindings where we
  * perpetually set it to quit when last win was closed. This changed
  * was necessary because in C++ binding as the elm mainloop stop
  * running all object are destroyed, references are unreferenced and
@@ -660,7 +660,7 @@
  * @until elm_policy_set
  
  * As you can see, the policy we chose was to quit when the last win
- * is hidden as opose to examples with the C bindings where we
+ * is hidden as opposed to examples with the C bindings where we
  * perpetually set it to quit when last win was closed. This changed
  * was necessary because in C++ binding as the elm mainloop stop
  * running all object are destroyed, references are unreferenced and
@@ -837,7 +837,7 @@
  * @until elm_policy_set
  
  * As you can see, the policy we chose was to quit when the last win
- * is hidden as opose to examples with the C bindings where we
+ * is hidden as opposed to examples with the C bindings where we
  * perpetually set it to quit when last win was closed. This changed
  * was necessary because in C++ binding as the elm mainloop stop
  * running all object are destroyed, references are unreferenced and
@@ -1030,13 +1030,13 @@
 
  * For the up button, we'll set to @p true the autorepeat,
  * autorepeat_initial_timeout, autoreapet_gap_timeout, the size hints
- * for weight and alignement, choose our packing method and making out
+ * for weight and alignment, choose our packing method and making out
  * up button visible.
 
  * @skip up
  * @until visibility
 
- * For this directional buttons we'll have a diferent repeated
+ * For this directional buttons we'll have a different repeated
  * callback that will insure the timeouts of our middle button in the
  * gap and initial timeout that is current setted.
 
@@ -1123,7 +1123,7 @@
  * @until elm_policy_set
  
  * As you can see, the policy we chose was to quit when the last win
- * is hidden as opose to examples with the C bindings where we
+ * is hidden as opposed to examples with the C bindings where we
  * perpetually set it to quit when last win was closed. This changed
  * was necessary because in C++ binding as the elm mainloop stop
  * running all object are destroyed, references are unreferenced and
@@ -1258,7 +1258,7 @@
  * @until elm_policy_set
  
  * As you can see, the policy we chose was to quit when the last win
- * is hidden as opose to examples with the C bindings where we
+ * is hidden as opposed to examples with the C bindings where we
  * perpetually set it to quit when last win was closed. This changed
  * was necessary because in C++ binding as the elm mainloop stop
  * running all object are destroyed, references are unreferenced and
@@ -1441,7 +1441,7 @@
  * @until elm_policy_set
  
  * As you can see, the policy we chose was to quit when the last win
- * is hidden as opose to examples with the C bindings where we
+ * is hidden as opposed to examples with the C bindings where we
  * perpetually set it to quit when last win was closed. This changed
  * was necessary because in C++ binding as the elm mainloop stop
  * running all object are destroyed, references are unreferenced and
@@ -1580,7 +1580,7 @@
  * @until elm_policy_set
  
  * As you can see, the policy we chose was to quit when the last win
- * is hidden as opose to examples with the C bindings where we
+ * is hidden as opposed to examples with the C bindings where we
  * perpetually set it to quit when last win was closed. This changed
  * was necessary because in C++ binding as the elm mainloop stop
  * running all object are destroyed, references are unreferenced and
@@ -1825,7 +1825,7 @@
  * @until elm_policy_set
  
  * As you can see, the policy we chose was to quit when the last win
- * is hidden as opose to examples with the C bindings where we
+ * is hidden as opposed to examples with the C bindings where we
  * perpetually set it to quit when last win was closed. This changed
  * was necessary because in C++ binding as the elm mainloop stop
  * running all object are destroyed, references are unreferenced and
@@ -1992,7 +1992,7 @@
  * @until elm_policy_set
  
  * As you can see, the policy we chose was to quit when the last win
- * is hidden as opose to examples with the C bindings where we
+ * is hidden as opposed to examples with the C bindings where we
  * perpetually set it to quit when last win was closed. This changed
  * was necessary because in C++ binding as the elm mainloop stop
  * running all object are destroyed, references are unreferenced and
@@ -2127,7 +2127,7 @@
  * @skip pack_end
  * @until visibility
 
- * The second clock shows ther am/pm time, that we also create with
+ * The second clock shows the am/pm time, that we also create with
  * the C++ binding method, passing our window object as
  * parent. Setting show_am_pm to true and again choosing the packing
  * method and making clock visible.
@@ -2205,7 +2205,7 @@
  * @until elm_policy_set
  
  * As you can see, the policy we chose was to quit when the last win
- * is hidden as opose to examples with the C bindings where we
+ * is hidden as opposed to examples with the C bindings where we
  * perpetually set it to quit when last win was closed. This changed
  * was necessary because in C++ binding as the elm mainloop stop
  * running all object are destroyed, references are unreferenced and
@@ -2419,7 +2419,7 @@
  * @until visibility
 
  * For our second datetime, we'll also set the size hints weight and
- * align, but in this case, the filds YEAR, MONTH and DATE will be not
+ * align, but in this case, the fields YEAR, MONTH and DATE will be not
  * visible, and thus displaying in our datetime the hour, minute and
  * AM/PM. Finally we choose it's packing method and set the visibility
  * of datetime to @p true.
@@ -2513,7 +2513,7 @@
  * @until linked
 
  * In this function we load the vertex/fragment shaders, create the
- * program object and finish our funtion.
+ * program object and finish our function.
 
  * @skip gld
  * @until return 1;
@@ -2585,7 +2585,7 @@
  * @skipline elm_policy_set
  
  * As you can see, the policy we chose was to quit when the last win
- * is hidden as opose to examples with the C bindings where we
+ * is hidden as opposed to examples with the C bindings where we
  * perpetually set it to quit when last win was closed. This changed
  * was necessary because in C++ binding as the elm mainloop stop
  * running all object are destroyed, references are unreferenced and
@@ -2883,7 +2883,7 @@
  * @skipline elm_policy_set
  
  * As you can see, the policy we chose was to quit when the last win
- * is hidden as opose to examples with the C bindings where we
+ * is hidden as opposed to examples with the C bindings where we
  * perpetually set it to quit when last win was closed. This changed
  * was necessary because in C++ binding as the elm mainloop stop
  * running all object are destroyed, references are unreferenced and
@@ -3031,7 +3031,7 @@
  * @until elm_policy_set
  
  * As you can see, the policy we chose was to quit when the last win
- * is hidden as opose to examples with the C bindings where we
+ * is hidden as opposed to examples with the C bindings where we
  * perpetually set it to quit when last win was closed. This changed
  * was necessary because in C++ binding as the elm mainloop stop
  * running all object are destroyed, references are unreferenced and
@@ -3248,7 +3248,7 @@
  * @skipline elm_policy_set
  
  * As you can see, the policy we chose was to quit when the last win
- * is hidden as opose to examples with the C bindings where we
+ * is hidden as opposed to examples with the C bindings where we
  * perpetually set it to quit when last win was closed. This changed
  * was necessary because in C++ binding as the elm mainloop stop
  * running all object are destroyed, references are unreferenced and
@@ -3462,7 +3462,7 @@
  * @skipline elm_policy_set
  
  * As you can see, the policy we chose was to quit when the last win
- * is hidden as opose to examples with the C bindings where we
+ * is hidden as opposed to examples with the C bindings where we
  * perpetually set it to quit when last win was closed. This changed
  * was necessary because in C++ binding as the elm mainloop stop
  * running all object are destroyed, references are unreferenced and
@@ -3604,7 +3604,7 @@
  * @until elm_policy_set
  
  * As you can see, the policy we chose was to quit when the last win
- * is hidden as opose to examples with the C bindings where we
+ * is hidden as opposed to examples with the C bindings where we
  * perpetually set it to quit when last win was closed. This changed
  * was necessary because in C++ binding as the elm mainloop stop
  * running all object are destroyed, references are unreferenced and
@@ -3736,7 +3736,7 @@
  * @until elm_policy_set
  
  * As you can see, the policy we chose was to quit when the last win
- * is hidden as opose to examples with the C bindings where we
+ * is hidden as opposed to examples with the C bindings where we
  * perpetually set it to quit when last win was closed. This changed
  * was necessary because in C++ binding as the elm mainloop stop
  * running all object are destroyed, references are unreferenced and
@@ -3997,7 +3997,7 @@
  * @dontinclude separator_cxx_example_01.cc
 
  * Separator is a very thin object used to separate other objects,
- * wich can be vertical or horizontal.
+ * which can be vertical or horizontal.
 
  * This example shows how to create a window and separate in two
  * parts, each one will be filled with a background color to show the
@@ -4031,7 +4031,7 @@
  * @until elm_policy_set
  
  * As you can see, the policy we chose was to quit when the last win
- * is hidden as opose to examples with the C bindings where we
+ * is hidden as opposed to examples with the C bindings where we
  * perpetually set it to quit when last win was closed. This changed
  * was necessary because in C++ binding as the elm mainloop stop
  * running all object are destroyed, references are unreferenced and
@@ -4268,7 +4268,7 @@
  * @until elm_policy_set
  
  * As you can see, the policy we chose was to quit when the last win
- * is hidden as opose to examples with the C bindings where we
+ * is hidden as opposed to examples with the C bindings where we
  * perpetually set it to quit when last win was closed. This changed
  * was necessary because in C++ binding as the elm mainloop stop
  * running all object are destroyed, references are unreferenced and
@@ -4573,7 +4573,7 @@
  * @until elm_policy_set
  
  * As you can see, the policy we chose was to quit when the last win
- * is hidden as opose to examples with the C bindings where we
+ * is hidden as opposed to examples with the C bindings where we
  * perpetually set it to quit when last win was closed. This changed
  * was necessary because in C++ binding as the elm mainloop stop
  * running all object are destroyed, references are unreferenced and
@@ -4874,7 +4874,7 @@
  * @until elm_policy_set
  
  * As you can see, the policy we chose was to quit when the last win
- * is hidden as opose to examples with the C bindings where we
+ * is hidden as opposed to examples with the C bindings where we
  * perpetually set it to quit when last win was closed. This changed
  * was necessary because in C++ binding as the elm mainloop stop
  * running all object are destroyed, references are unreferenced and
@@ -4958,15 +4958,15 @@
 
  * @li row - Row number
 
- * @li colspan - Number of columns that the subobj will occuppy
+ * @li colspan - Number of columns that the subobj will occupy
 
- * @li rowspan - Number of rows that the subobj will occuppy
+ * @li rowspan - Number of rows that the subobj will occupy
  
  * @note All positioning inside the table is relative to rows and
  * columns, so a value of 0 for @a column and @a row, means the top
  * left cell of the table. And for example, value of 2 for @a colspan and @a
- * rowspan indicates that the subobj will occuppy two column and two rows,
- * thus occuppying 4 cells in total.
+ * rowspan indicates that the subobj will occupy two columns and two rows,
+ * thus occupying 4 cells in total.
 
  * Finally we just have to make our window visible. Then run the elm
  * mainloop, starting to handle events and drawing operations.
@@ -5018,7 +5018,7 @@
  * @until elm_policy_set
  
  * As you can see, the policy we chose was to quit when the last win
- * is hidden as opose to examples with the C bindings where we
+ * is hidden as opposed to examples with the C bindings where we
  * perpetually set it to quit when last win was closed. This changed
  * was necessary because in C++ binding as the elm mainloop stop
  * running all object are destroyed, references are unreferenced and
@@ -5075,7 +5075,7 @@
  * @until homogeneous
 
  * For each cell of this table we are going to create a unique @p
- * evas::rectangle, each with diferent colors and sizes.
+ * evas::rectangle, each with different colors and sizes.
 
  * Let's see a snip of the code on how we constructed our rectangles
  * and setted the colors.
@@ -5120,15 +5120,15 @@
 
  * @li row - Row number
 
- * @li colspan - Number of columns that the subobj will occuppy
+ * @li colspan - Number of columns that the subobj will occupy
 
- * @li rowspan - Number of rows that the subobj will occuppy
+ * @li rowspan - Number of rows that the subobj will occupy
  
  * @note All positioning inside the table is relative to rows and
  * columns, so a value of 0 for @a column and @a row, means the top
  * left cell of the table. And for example, value of 2 for @a colspan
- * and @a rowspan indicates that the subobj will occuppy two column
- * and two rows, thus occuppying 4 cells in total.
+ * and @a rowspan indicates that the subobj will occupy two column
+ * and two rows, thus occupying 4 cells in total.
 
  * So for each rectangle we are setting a specific location and how
  * many cells it's occupying, better seem below:
@@ -5202,7 +5202,7 @@
  * @skipline elm_policy_set
  
  * As you can see, the policy we chose was to quit when the last win
- * is hidden as opose to examples with the C bindings where we
+ * is hidden as opposed to examples with the C bindings where we
  * perpetually set it to quit when last win was closed. This changed
  * was necessary because in C++ binding as the elm mainloop stop
  * running all object are destroyed, references are unreferenced and
@@ -5329,4 +5329,4 @@
 
  * @image latex screenshots/thumb_cxx_example_01.eps width=\textwidth
  * @example thumb_cxx_example_01.cc
- */
\ No newline at end of file
+ */
diff --git a/doc/elementary_examples_js.dox b/doc/elementary_examples_js.dox
index 37f867a638..bcd119bdab 100644
--- a/doc/elementary_examples_js.dox
+++ b/doc/elementary_examples_js.dox
@@ -627,7 +627,7 @@
  * @skip pack_end
  * @until visible
 
- * The second clock shows ther am/pm time, that we also create with
+ * The second clock shows the am/pm time, that we also create with
  * the JS binding method, passing our window object as
  * parent. Setting show_am_pm to true and again choosing the packing
  * method and making clock visible.
@@ -701,7 +701,7 @@
  * @dontinclude separator_example_01.js
 
  * Separator is a very thin object used to separate other objects,
- * wich can be vertical or horizontal.
+ * which can be vertical or horizontal.
 
  * This example shows how to create a window and separate in two
  * parts, each one will be filled with a background color to show the
@@ -1019,4 +1019,4 @@
  * @image latex screenshots/icon_example_01.eps width=\textwidth
  
  * @example icon_example_01.js
- */
\ No newline at end of file
+ */