Small typo fixes

Author: PoignardAzur

docs/src/02_getting_started.md

@@ -181,7 +181,7 @@ To complete our todo-list, we need to change our app data type. Instead of just
 {{#include ../book_examples/src/getting_started_2_md.rs:example_6_struct}}
 ```
 
-However, now we have a problem: our List widget which expected a `Vector<...>` won't know how to handle a struct. So, we need to modify druid's dataflow so that, given the TodoList above, the List widget will have access to the `items` field. This is done with a `Lens`, which we'll explain next chapter.
+However, now we have a problem: our List widget which expected a `Vector<...>` won't know how to handle a struct. So, we need to modify Druid's dataflow so that, given the TodoList above, the List widget will have access to the `items` field. This is done with a `Lens`, which we'll explain next chapter.
 
 Furthermore, to pass our type as the a generic parameter to `Widget`, we need it to implement the `Data` trait (and `Clone`), more on that next chapter.
 

docs/src/03_data.md

@@ -8,7 +8,7 @@ Some widgets (eg Button, TextBox, Checkbox) can mutate the data passed to them b
 
 When you mutate a widget's associated data, Druid compares the old and new version, and propagates the change to the widgets that are affected by the change.
 
-Note that, in all that workflow, Widgets don't actually store their associated data. A `Button<Vector<String>>` doesn't actually store a `Vector<String>`, the framework just stores one which is provided to the button.
+Note that, in all that workflow, Widgets don't actually store their associated data. A `Button<Vector<String>>` doesn't actually store a `Vector<String>`, instead the framework stores one per button, which is provided to widget methods.
 
 For this to work, your model must implement the `Clone` and `Data` traits. The `Data` trait has a single method:
 
@@ -21,7 +21,7 @@ This method checks for equality, but allows for false negatives.
 
 ## Performance
 
-It is important that your data be cheap to clone and cheap to compare; we encourage the use of reference counted pointers to allow cheap cloning of more expensive types. `Arc` and `Rc` have blanket `Data` impls that do pointer comparison, so if you have a type that does not implement `Data`, you can always just wrap it in one of those smart pointers.
+It is important that your data is cheap to clone and cheap to compare; we encourage the use of reference counted pointers to allow cheap cloning of more expensive types. `Arc` and `Rc` have blanket `Data` impls that do pointer comparison, so if you have a type that does not implement `Data`, you can always just wrap it in one of those smart pointers.
 
 ### Collections
 
@@ -31,7 +31,7 @@ issues with collection types. For this reason, `Data` is not implemented for
 
 You can always put these types inside an `Rc` or an `Arc`, or if you're dealing with
 larger collections you can build Druid with the `im` feature, which brings in
-the [`im crate`], and adds a `Data` impl for the collections there. The [`im`
+the [`im` crate], and adds a `Data` impl for the collections there. The [`im`
 crate] is a collection of immutable data structures that act a lot like the `std`
 collections, but can be cloned efficiently.
 
@@ -58,7 +58,7 @@ Here is an example of using `Data` to implement a simple data model:
 
 In Druid, most container widgets expect their children to have the same associated data. If you have a `Flex<Foobar>`, you can only append widgets that implement `Widget<Foobar>` to it.
 
-In some cases, however, you want compose widgets that operate on different subsets of the data. Maybe you want to add two widgets to the above Flex, one that uses the field `foo` and another that uses the field `bar`, and they might respectively implement `Widget<Foo>` and `Widget<Bar>`.
+In some cases, however, you want to compose widgets that operate on different subsets of the data. Maybe you want to add two widgets to the above Flex, one that uses the field `foo` and another that uses the field `bar`, and they might respectively implement `Widget<Foo>` and `Widget<Bar>`.
 
 Lenses allow you to bridge that type difference. A lens is a type that represents a *two-way* mapping between two data types. That is, a lens from X to Y can take an instance of X and give you an instance of Y, and can take a modified Y and apply the modification to X.
 

druid/src/core.rs

@@ -232,8 +232,8 @@ impl<T, W: Widget<T>> WidgetPod<T, W> {
     /// with behavior similar to a button will call [`set_active`] on mouse
     /// down and then up.
     ///
-    /// The active status can only be set manually. Druid doesn't eg automatically
-    /// set it to false on mouse release.
+    /// The active status can only be set manually. Druid doesn't automatically
+    /// set it to `false` on mouse release or anything like that.
     ///
     /// There is no special handling of the active status for multi-pointer devices.
     ///

druid/src/widget/flex.rs

@@ -571,7 +571,7 @@ impl<T: Data> Flex<T> {
                 flex: params.flex,
             }
         } else {
-            tracing::warn!("Flex value should be > 0.0. To add a non-flex child use the add_child or with_child methods.\nSee the docs for more information: https://docs.rs/druid/latest/druid/widget/struct.Flex.html");
+            tracing::warn!("Flex value should be > 0.0. To add a non-flex child use the add_child or with_child methods.\nSee the docs for more information: https://docs.rs/druid/0.8.0/druid/widget/struct.Flex.html");
             Child::Fixed {
                 widget: WidgetPod::new(Box::new(child)),
                 alignment: None,