Spelling and editorial changes

Signed-off-by: Dan Yeaw <dan@yeaw.me>

docs/event_system.md

@@ -2,20 +2,21 @@
 
 The Generic library provides the `generic.event` module which is used to
 implement the event system in Gaphor. This event system in Gaphor provides an
-API to *subscribe* to events and to then *handle* those events so previously
+API to *subscribe* to events and to then *handle* those events so that
-subscribed *handlers* are being executed.
+previously subscribed *handlers* are executed.
 
-In Gaphor event handler subscribtions are managed through the EventManager service. Gaphor is highly event driven:
+In Gaphor we manage event handler subscriptions through the EventManager
+service. Gaphor is highly event driven:
 
  * Changes in the loaded model are emitted as events
  * Changes on diagrams are emitted as events
  * Changes in the UI are emitted as events
 
-Although Gaphor depends heavily on GTK got it's user interface, Gaphor is using
+Although Gaphor depends heavily on GTK for its user interface, Gaphor is using
-it's own event dispatcher. Events can be structured in hierarchies. For
+its own event dispatcher. Events can be structured in hierarchies. For example,
-example: an AttributeUpdated event is a subtype of ElementUpdated. If I'm
+an AttributeUpdated event is a subtype of ElementUpdated. If we are interested
-interested in all changes done to elements I can register to ElementUpdated and
+in all changes to elements, we can also register ElementUpdated and receive all
-recieve all AttributeUpdated events as well.
+AttributeUpdated events as well.
 
 ```eval_rst
 .. autoclass:: gaphor.core.eventmanager.EventManager

docs/framework.md

@@ -40,7 +40,7 @@ The most notable services are:
 
 ### event_manager
 
-This is the central compoment used for event dispatching. Every service that
+This is the central component used for event dispatching. Every service that
 does something with events (both sending and receiving) depends on this
 component.
 

docs/model.md

@@ -15,7 +15,7 @@ Pay attention to the following changes/additions with respect to the
 official Gaphor model, in the `models/UML.gaphor` file:
 
 -   Additions to the model have been put in the package
-    AuxilaryConstructs.Presentations and .Stereotypes.
+    AuxiliaryConstructs.Presentations and .Stereotypes.
 -   A Diagram element is added in order to model the diagrams.
 -   A special construct has been put into place in order to apply
     stereotypes to model elements. The current UML Specification is not

docs/modeling_language.md

@@ -8,24 +8,30 @@ The main language was, and will be UML. Gaphor now also supports a subset of
 SysML.
 
 A ModelingLanguage in Gaphor is defined by a class implementing the
-`gaphor.abc.ModelingLanguage` abstract base class. The modeling language should be registered as a gaphor.modelinglanguages entry point.
+`gaphor.abc.ModelingLanguage` abstract base class. The modeling language should
+be registered as a `gaphor.modelinglanguage` entry point.
 
-The ModelingLannguage interface is fairly minimal. It allows other services to
+The ModelingLanguage interface is fairly minimal. It allows other services to
-look up elements and diagram items, as well as a toolbox.
+look up elements and diagram items, as well as a toolbox. However, the
-However, the responsibilities of a ModelingLanguage do not stop there. Parts of functionality will be implemented by registering handlers to a set of generic functions.
+responsibilities of a ModelingLanguage do not stop there. Parts of
+functionality will be implemented by registering handlers to a set of generic
+functions.
 
-But let's not get ahead of ourselves. What is the functionality a modeling language implementation can offer?
+But let's not get ahead of ourselves. What is the functionality a modeling
+language implementation can offer?
 
 * A data model (elements)
 * Diagram items
 * A toolbox definition
 * Connectors, allow diagram items to connect
 * Grouping
-* Editor pages, shown in the collabsable pane on the right side
+* Editor pages, shown in the collapsable pane on the right side
 * Inline (diagram) editor popups
-* Copy/paste behavior when element copying is not trivial (e.i. more than one element is involved)
+* Copy/paste behavior when element copying is not trivial, for example with
+  more than one element is involved
 
-The first three are exposed by methods defined on the ModelingLanguage class. All others are exposed by adding handlers to the respective generic functions.
+We expose the first three by methods defined on the ModelingLanguage class. We
+then expose the others by adding handlers to the respective generic functions.
 
 
 ```eval_rst

docs/service_oriented.md

@@ -2,19 +2,20 @@
 
 Gaphor has a service oriented architecture. What does this mean? Well, Gaphor
 is built as a set of small islands (services). Each island provides a specific
-piece of functionality. For example, separate services are used to load/save
+piece of functionality. For example, we use separate services to load/save
-models, provide the menu structure, and handle the undo system.
+models, provide the menu structure, and to handle the undo system.
 
-Service are defined as entry points in the `pyproject.toml`. With entry points
+We define services as entry points in the `pyproject.toml`. With entry points,
-applications can register functionality for specific purposes. Entry points are
+applications can register functionality for specific purposes. We also group
-grouped in so called *entry point groups*. For example the console_scripts
+entry points in to *entry point groups*. For example, we use the
-entry point group is used to start an application from the command line.
+console_scripts entry point group to start an application from the command
+line.
 
 
 ## Services
 
-Gaphor is modeled around the concept of Services. Each service can be
+Gaphor is modeled around the concept of services. Each service can be
-registered with the application and then be used by other services or
+registered with the application and then it can be used by other services or
 other objects living within the application.
 
 Each service should implement the Service interface. This interface
@@ -24,18 +25,18 @@ defines one method:
 
 Which is called when a service needs to be cleaned up.
 
-Each service is allowed to define its own methods, as long as Service
+We allow each service to define its own methods, as long as the service
 is implemented too.
 
 Services should be defined as entry points in the `pyproject.toml` file.
 
-Typically a service does some work in the background. Service can also expose
+Typically, a service does some work in the background. Services can also expose
 actions that can be invoked by users. For example, the _Ctrl-z_ key combo
 (undo) is implemented by the UndoManager service.
 
-A service can depend on another services. Dependencies are resolved during
+A service can also depend on another services. Service initialization resolves
-service initialization. To define a service dependency, just add it to the
+these dependencies. To define a service dependency, just add it to the
-constructor by it's name defined in the entrypoint:
+constructor by its name defined in the entry point:
 
     class MyService(Service):
 
@@ -52,7 +53,7 @@ constructor by it's name defined in the entrypoint:
 
 Services that expose actions should also inherit from the ActionProvider
 interface. This interface does not require any additional methods to be
-implemented. Action methods should be annotated with a `@action` annotation.
+implemented. Action methods should be annotated with an `@action` annotation.
 
 ## Example: ElementFactory