Merge pull request #83 from benstafford/fix-guides-spelling

Fix guides wording and spelling
Thank you!

Author: boydm

guides/getting_started.md

@@ -5,7 +5,7 @@ building your first Scenic application.
 
 ## Install `scenic.new`
 
-The Scenic Archive is the home of the `scenic.new` mix task, which layout a
+The Scenic Archive is the home of the `scenic.new` mix task, which lays out a
 starter application for you. This is the easiest way to set up a new Scenic
 project.
 
@@ -51,7 +51,7 @@ configurations should live in your app's config.exs file.
       ]
     }
 
-Then use that config for start your supervisor with the `Scenic` supervisor.
+Then use that config to start your supervisor with the `Scenic` supervisor.
 
 ```elixir
 defmodule MyApp do
@@ -112,7 +112,7 @@ Scenic application. It has four scenes, two components, and a simulated sensor.
 
 - **Splash:** The Splash scene is configured to run when the app is started in
   the `config/config.exs` file. It runs a simple animation, then transitions to
-  the Sensor scene. It also shows how intercept basic user input to exit the
+  the Sensor scene. It also shows how to intercept basic user input to exit the
   scene early.
 
 - **Sensor:** The Sensor scene depicts a simulated temperature sensor. The

guides/getting_started_nerves.md

@@ -1,3 +1,3 @@
-Placesholder for getting started with Nerves
+Placeholder for getting started with Nerves
 
-Coming soon
+Coming soon

guides/overview_scene.md

@@ -1,6 +1,6 @@
 # Structure of a Scene
 
-A `Scenic.Scene` is a `GenServer` process which creates and manages a [Graph](overview_graph.html) that gets drawn to the screen. Scenes also respondss to user input and other events.
+A `Scenic.Scene` is a `GenServer` process which creates and manages a [Graph](overview_graph.html) that gets drawn to the screen. Scenes also respond to user input and other events.
 
 Scenes can reference each other, creating a logical hierarchy that lives above
 the Graphs themselves. This allows scenes to be reusable, small, and simple. A
@@ -11,7 +11,7 @@ Scenes that are specifically meant to be reused are called components.
 Components have sugar apis that make them very easy to use inside of a parent
 scene.
 
-For example, if you create a dashboard. It may have buttons, text input,
+For example, if you create a dashboard, it may have buttons, text input,
 sliders, or other input controls in it. Each of those controls is a component
 scene that is dynamically created when the dashboard scene is started. This
 collection of scenes forms a graph, which can be quite deep (scenes using scenes
@@ -30,7 +30,7 @@ defines what is to be drawn to the screen, any referenced components, and the
 overall draw order. When the Scene decides the graph is ready to be drawn to the
 screen, it pushes it to the Viewport.
 
-In general, a graph is immutable data structure that you manipulate through
+In general, a graph is an immutable data structure that you manipulate through
 transform functions. In the example below `Graph.build()` creates an empty
 graph, which is piped into functions that add things to it. The `text/3`
 function accepts a graph, adds some text to it, then applies a list of options
@@ -130,7 +130,7 @@ option      | description
 ----------- | -----------
 `:id`       | If this scene is a component, then the id that was assigned to its reference in the parent's graph is passed in as the `:id` option. Typically, controls that generate and send events to its parent scene use this id to identify themselves. If this is the root scene, the id will not be set.
 `:styles`   | This is the map of styles inherited from the parent graph. The scene can use these styles (or not) as makes sense for its needs.
-`:viewport` | This is gives the pid of the viewport running this scene. It is very useful if you want to generate input or change the currently showing scene. If you are managing the scene in your own supervisor, it will not be set. See [life-cycle of a scene](scene_lifecycle.html) for more information.
+`:viewport` | This gives the pid of the viewport running this scene. It is very useful if you want to generate input or change the currently showing scene. If you are managing the scene in your own supervisor, it will not be set. See [life-cycle of a scene](scene_lifecycle.html) for more information.
 
 ## Pushing a Graph
 
@@ -183,7 +183,7 @@ event that you handle.
 ## User Input
 
 A Scene also responds to messages. The two types of messages Scenic will send to
-scene are user input, and events.
+the scene are user input and events.
 
 ## Events
 
@@ -198,7 +198,7 @@ to use from within another scene. To make a component, call the
 `use Scenic.Component` macro instead of the Scene version.
 
 You will then need to add `info/0` and `verify/1` callbacks. The `verify/1`
-accepts the `scene_args`parameter that will be passed to the `init/2` function,
+accepts the `scene_args` parameter that will be passed to the `init/2` function
 and verifies that it is correctly formatted. If it is correct, return
 `{:ok, data}`. If it is not ok, return `:invalid_data`.
 
@@ -274,5 +274,5 @@ With helper functions, the above graph would be re-written like this:
 ## What to read next?
 
 Next, you should read about the [life-cycle of a scene](scene_lifecycle.html).
-This will explain how scenes get started, when the stop, and how they relate to
-each other.
+This will explain how scenes get started, when they stop, and how they relate to
+each other.

guides/overview_styles.md

@@ -2,7 +2,7 @@
 
 Styles are optional modifiers that you can put on any primitive. Each style does a specific thing and some only affect certain primitives.
 
-There is a fixed list of primitives styles, which are understood by the drivers. Some Components may introduce their own optional styles, but the only ones sent down to the drivers for rendering is the list below.
+There is a fixed list of primitive styles which are understood by the drivers. Some Components may introduce their own optional styles, but the only ones sent down to the drivers for rendering are contained in the list below.
 
 In general, the primitive styles are each defined in their own module, but you apply them as options in a primitive's option list.
 
@@ -34,7 +34,7 @@ The `Fill` and `Stroke` styles accept a paint type. This describes what to fill
 
 There is a fixed set of paint types that the drivers know how to render.
 
-* [`BoxGradient`](Scenic.Primitive.Style.Paint.BoxGradient.html) fills an primitive with a box gradient.
+* [`BoxGradient`](Scenic.Primitive.Style.Paint.BoxGradient.html) fills a primitive with a box gradient.
 * [`Color`](Scenic.Primitive.Style.Paint.Color.html) fills a primitive with a solid color. 
 * [`Image`](Scenic.Primitive.Style.Paint.Image.html) fills a primitive with an image that is loaded into `Scenic.Cache`.
 * [`LinearGradient`](Scenic.Primitive.Style.Paint.LinearGradient.html) fills a primitive with a linear gradient.

guides/scene_lifecycle.md

@@ -1,6 +1,6 @@
 # Life-cycle of a Scene
 
-A very important part of Scenic is the Scene life-cycle management. Most scenes' live-cycles will be managed automatically by their [ViewPort](overview_viewport.html). The ViewPort determines when to start and stop these dynamic scenes.
+A very important part of Scenic is the Scene life-cycle management. Most scenes' life-cycles will be managed automatically by their [ViewPort](overview_viewport.html). The ViewPort determines when to start and stop these dynamic scenes.
 
 In effect, when you create a graph and add components like `button`, `checkbox` and more, you are doing more than just saying, "Draw a button here". You instructing the `ViewPort` how and when to start and stop the processes that drive those components.