kozorizki/gaphor
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Spelling and editorial changes

Browse Source 
Signed-off-by: Dan Yeaw <dan@yeaw.me>
This commit is contained in:
Dan Yeaw 2020-05-14 20:37:14 -04:00
parent ff5c872026
commit fffc2b310d
No known key found for this signature in database
GPG Key ID: 77A923EF537B61A4
5 changed files with 40 additions and 32 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

17
docs/event_system.md
View File

@ -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
subscribed *handlers* are being executed.
API to *subscribe* to events and to then *handle* those events so that
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
it's own event dispatcher. Events can be structured in hierarchies. For
example: an AttributeUpdated event is a subtype of ElementUpdated. If I'm
interested in all changes done to elements I can register to ElementUpdated and
recieve all AttributeUpdated events as well.
Although Gaphor depends heavily on GTK for its user interface, Gaphor is using
its own event dispatcher. Events can be structured in hierarchies. For example,
an AttributeUpdated event is a subtype of ElementUpdated. If we are interested
in all changes to elements, we can also register ElementUpdated and receive all
AttributeUpdated events as well.
```eval_rst
.. autoclass:: gaphor.core.eventmanager.EventManager

2
docs/framework.md
View File

@ -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.

2
docs/model.md
View File

@ -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

22
docs/modeling_language.md
View File

@ -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
look up elements and diagram items, as well as a toolbox.
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.
The ModelingLanguage interface is fairly minimal. It allows other services to
look up elements and diagram items, as well as a toolbox. 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.
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

29
docs/service_oriented.md
View File

@ -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
models, provide the menu structure, and handle the undo system.
piece of functionality. For example, we use separate services to load/save
models, provide the menu structure, and to handle the undo system.
Service are defined as entry points in the `pyproject.toml`. With entry points
applications can register functionality for specific purposes. Entry points are
grouped in so called *entry point groups*. For example the console_scripts
entry point group is used to start an application from the command line.
We define services as entry points in the `pyproject.toml`. With entry points,
applications can register functionality for specific purposes. We also group
entry points in to *entry point groups*. For example, we use the
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
registered with the application and then be used by other services or
Gaphor is modeled around the concept of services. Each service can be
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
service initialization. To define a service dependency, just add it to the
constructor by it's name defined in the entrypoint:
A service can also depend on another services. Service initialization resolves
these dependencies. To define a service dependency, just add it to the
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