-The second part of the program was the graphical user interface, including all the graphical classes. The main class of the interface was named MooGUI. Since we had decided to use Swing in building the interface, this class was naturally to extend JFrame. Here, all other GUI components were to be created. Most of these components - maintaining different kinds of data, having listeners and requiring different methods for update their content - were to be quite complex, and were therefore given their own classes. Among these are graphical classes that construct the menu, the toolbar and the view of the MIDI tracks. All these classes [...]. \r
-\r
-Apart from the strictly graphical classes we decided to make a graphical representation of the functional classes, this to get an better overview of our work [...]. MooView (a graphical representation of MooSequence), MooTrackView and MooTrackTitle (MooTrack), and MooNoteElement (MooNote). Supporting these components, some other graphical classes were needed: MooViewCounter, representing a ruler that visualizes the time signature of the MIDI file; MooTrackTitle, handling the properties of a track; and MooNoteElement, supplying a way of editing the properties of a note.\r
-\r
-We design the structure of the application very quickly, perhaps to quickly. We were not entirely certain of how the Java MIDI package worked. As our work with the project progressed, we were forced to reevaluate some of these design decisions and change the system design (see section [Major Decissions]).\r
-------------------------------\r
-2.3 Time Schedule\r
-Before we started implement the classes, we made an time-schedule for each class, and divided the classes between us. Later we realeased that for a few classes this time-schedule were very optimistic. The consequences of a misleading time-schedule were that some classes was not implemented before a very long time in the project.\r
-------------------------------\r
-2.4 Implemention\r
-As we earlier realised we needed to implement the functional classes first. This to see what references the graphical representation might call. [...]\r
- Strictly graphical classes [...]\r
-------------------------------\r
-2.5 Testing\r
-------------------------------\r
-2.6 Major Decisions\r
+The second part of the program was the graphical user interface, including all the graphical classes. The main class of the interface was named MooGUI. Since we had decided to use Swing in building the interface, this class was naturally to extend JFrame. Here, all other GUI components were to be created. Most of these components - maintaining different kinds of data, having listeners and requiring different methods for update their content - were to be quite complex, and were therefore given their own classes. Among these are graphical classes that construct the menu, the toolbar and the view of the MIDI tracks. All these classes [...].
+
+Apart from the strictly graphical classes we decided to make a graphical representation of the functional classes, this to get an better overview of our work [...]. MooView (a graphical representation of MooSequence), MooTrackView and MooTrackTitle (MooTrack), and MooNoteElement (MooNote). Supporting these components, some other graphical classes were needed: MooViewCounter, representing a ruler that visualizes the time signature of the MIDI file; MooTrackTitle, handling the properties of a track; and MooNoteElement, supplying a way of editing the properties of a note.
+
+We design the structure of the application very quickly, perhaps to quickly. We were not entirely certain of how the Java MIDI package worked. As our work with the project progressed, we were forced to reevaluate some of these design decisions and change the system design (see section [Major Decissions]).
+------------------------------
+2.3 Time Schedule
+Before we started implement the classes, we made an time-schedule for each class, and divided the classes between us. Later we realeased that for a few classes this time-schedule were very optimistic. The consequences of a misleading time-schedule were that some classes was not implemented before a very long time in the project.
+------------------------------
+2.4 Implemention
+As we earlier realised we needed to implement the functional classes first. This to see what references the graphical representation might call. [...]
+ Strictly graphical classes [...]
+------------------------------
+2.5 Testing
+------------------------------
+2.6 Major Decisions