Architecture

1. At the highest level, the Event Driven Application Manager consists of an EventHandler and an Application. EventHandler is an ApplicationManager, and usually obtains Mouse and KeyBoard events and sends them to the Application. The Application acts on the events and generates events for Mouse, KeyBoard, and Display objects.  Application tells it's ApplicationManager when it is finished.

 
2. To support a Graphical User Interface (GUI), a concrete implementation of Application is required to manage the graphical components and route physical (Mouse and KeyBoard) events (and possibly logical events).  This class is called VisualApplicationManager.

VisualApplicationManager is a VisualApplication, and has a list of VisualApplications, such as Text, ListBox, Menu, Image, VisualApplicationManager, etc.  The VisualApplications provide the Display aspect of the GUI using constant data values or by using a Publisher - Subscriber relationship with the underlying implementation Model.  They also provide control by supporting user interactions.  Concrete client implementations of various abstract VisualApplication classes implement control over the application Model.

VisualApplications have two states - open and closed.  VisualApplicationManager uses a concept of a current VisualApplication.  The current VisualApplication is open. KeyBoard events are then passed to the current VisualApplication, which may act on the event according to it's own responsibilities and internal implementation. VisualApplicationManager may filter out specific Key events for it's own use before passing them on to the current VisualApplication.  Since the current VisualApplication may also be an VisualApplicationManager, it too may filter out it's Key events, and so on.  When the current VisualApplication finally gets the Key event, it may not be able to use it, so the VisualApplicationManager gets a second opportunity to use the event.

When a Mouse buttonPressed event occurs VisualApplicationManager searches it's list of VisualApplications starting with the current one, and finds the one that the Mouse pointer is over.  If this is not the current one, the current one is closed and the one found is opened as the current VisualApplication.  The current VisualApplication is then sent the Mouse event.
 

3. A Publisher - Subscriber relation may be used to seperate the Model from the View/Controller.  Classes in the Model may be Publishers and any Visual component may become their Subscribers.