Main Classes

This section describes plans for morenaments 2 with respect to the classes encapsulating the main components of the application and their interaction.

AppInstance

A central class will hold references to the other main classes. Any class derived from AppComponent will have access to its app instance and, through it, to other core classes and common services like internationalization and logging. This is the default way of communication between quasi-singleton (i.e. once per AppInstance) classes.

Model

The model contains all the state of the application. The model should encapsulate its data to ensure consistency and forward compatibility. Elaborate calculations might be better off in the Controller.

ArtisticModel

Everything that a user would consider the "artistic content":

  • configured symmetry group
    • combinatorics
    • real degrees of freedom, e.g. vectors
  • view
    • zoom
    • origin
  • lines drawn by the user
    • color
    • line width
  • recognized background image

It should be possible to save the state represented by this class to a file.

CacheModel

Class caching useful information about the artistic model that can be dropped and recreated if the need arises. No caches get stored permanently.

InterfaceModel

Current state of the user interface:

  • mode of interaction
  • color
  • line width

It shouldn't be necessary to save any of these permanently.

ConfigModel

Stuff that a user might wish to save permanently:

  • kiosk mode configuration
  • color chooser setup
  • current file
  • recently opened files
  • current locale

Some of these settings should be saved in the registry or whatever preferences store the platform has to offer. When running as an applet, it should be possible to override these using parameters

GUIModel

Factory for Swing models for components, relating low-level widget state to high-level application state.

View

All view components communicate only with the model, not with one another. That way, parts of the view may be modified or completely dropped without affecting anything else. Suitable model listeners ensure that the view stays up to date.

AppletView, ApplicationView

Entry point classes implementing an Applet resp. a standalone or JNLP application.

LayoutView

Aligns all other things. Should probably have a factory method returning a single JPanel to be used as the content pane of whatever root container there is. Should also have a method returning a JMenuBar, so that the ApplicationView can use this as the system menu while the AppletView can embed it within the applet area.

Groups of controls that belong together should be encapsulated in a method returning a single JPanel for the whole group. That way, rearranging groups becomes fairly easy. Leaf components (and perhaps some non-trivial containers as well) should of course be implemented in their own respective classes.

CanvasView

Implementation of the main application canvas. Depending on current mode, different things will be displayed here. If hardware supports it, computations should be performed using OpenGL. Therefore different mode interfaces might be encapsulated in a class implementing CanvasMode and handling OpenGL rendering, Java2D rendering, and mouse interaction.

Controller

The controller handles non-trivial manipulations of model and view.

CommandsController

This would be a class implementing all menu and toolbar button actions, one method per action. Access to these methods would be faciliated via customized action listener classes and reflection. The benefit of having methods is that other parts of the application might call them as well, giving them at least as much power as the user has through the GUI, without the need to access GUI components. It also saves a lot of boilerplate code.

TasksController

Coordination of lengthy calculations performed on non-GUI threads.

Other central classes

I18n

Class providing internationalization services.