Updated to use new API

docs/quick_start.md

@@ -3,45 +3,44 @@
 ### The _engine_
 
 The first thing every Eventy-based application will need is an instance of the `Engine`.
-This provides the user with the basic event-loop functionality that eventy provides. It's
-the core of the whole framework that exists to have event-triggers ingested into its
-_queues_, checking those _queues_ and one by one dispatching each _signal handler_ that
-is associated with each queue on each item in the queue.
+This provides the user with a single object instance of the [`Engine` class]() by which
+the user can register _event types_, _signal handlers_ for said events and the ability
+to trigger or _push_ events into the engine.
 
 The simplest way to get a new _engine_ up and running is as follow:
 
 ```d
 Engine engine = new Engine();
-engine.start();
 ```
 
-This will create a new engine initializing all of its internals and then start it as well.
+This will create a new engine initializing all of its internals such that it is ready for
+use.
 
-### Queues
+### Event types
 
-_Queues_ are as they sound, a list containing items. Each queue has a unique ID which we
-can choose. The items of each queue will be the _events_ that are pushed into the _engine_.
-An _event_ has an ID associated with it which tells the _engine_ which queue it must be
-added to!
+_Event types_ are effectively just numbers. The use of these is to be able to connect events
+pushed into the engine with their respective signal handlers (which are registered to handle
+one or more event types).
 
-Let's create two queues, with IDs `1` and `2`:
+Let's create two event types, with IDs `1` and `2`:
 
 ```d
-engine.addQueue(1);
-engine.addQueue(2);
+engine.addEventType(new EventType(1));
+engine.addEventType(new EventType(2));
 ```
 
-This will tell the engine to create two new queues with tags `1` and `2` respectively.
+This will tell the engine to create two new event types with tags `1` and `2` respectively.
 
-### Event handlers
+### Signal handlers
 
-We're almost done. So far we have created a new _engine_ for handling our queues and
-the triggering of events. What is missing is something to _handle those queues_ when
-they have something added to them, we call this an _"event handler"_ in computer science
-but this is Eventy, and in Eventy this is known as a `Signal`.
+We're almost done. So far we have created a new _engine_ for handling our event tyoes and
+the triggering of events. What is missing is something to _handle those event types_ when
+an event of one of those types is pushed into the engine. Such handlers are referred to as
+_signal handlers_ and in Eventy these are instances of the [`Signal` class]().
 
-We're going to create a signal that can handle both the queues and perform the same task
-for both of them. We do this by creating a class that inherits from the `Signal` base type:
+We're going to create a signal that can handle both of the event types `1` and `2` that we
+registered earlier on. We can do this by creating a class that inherits from the `Signal`
+base class:
 
 ```d
 class SignalHandler1 : Signal
@@ -54,15 +53,15 @@ class SignalHandler1 : Signal
     public override void handler(Event e)
    	{
    		import std.stdio;
-   		writeln("Running event", e.id);
+   		writeln("Running event", e.getID());
    	}
 }
 ```
 
 We need to tell the `Signal` class two things:
 
-1. What _queue IDs_ it will handle
-2. What to _run_ for said queues
+1. What _event typess_ it will handle
+2. What to _run_ for said event types
 
 ---
 
@@ -83,7 +82,7 @@ two IDs, namely `1` and `2`.
 As for _what to run_, that is specified by overriding the `void handler(Event)` method
 in the `Signal` class. In our case we make it write to the console the ID of the event
 (which would end up either being `1` or `2` seeing as this handler is only registered
-for those queue IDs).
+for those event types).
 
 ```d
 import std.stdio;
@@ -111,8 +110,6 @@ engine.push(eTest);
 
 eTest = new Event(2);
 engine.push(eTest);
-
-
 ```
 
 You will then see something like this:
@@ -129,6 +126,6 @@ Running event1
 Running event2
 ```
 
-The reason is it depends on which process gets shceduled by the Linux kernel first, this
-is because new threads (special types of processes) are spanwed on the dispatch of each
-event.
+Despite us pushing the events into the engine in the order of `1` and _then_ `2`, the
+scheduling of such threads is up to the Linux kernel and hence one could be run before
+the other.