*** empty log message ***

diff --git a/report.txt b/report.txt
index 400585eba7cced2718eebfbcf9b2fbaaa7689935..fbab898b73941c3daf902fece6abd14aca378bcd 100644 (file)
--- a/report.txt
+++ b/report.txt
@@ -21,7 +21,7 @@ x MooSequence         The functional representation of a MIDI sequence. Was to extend J
 x MooTrack     The functional representation of a MIDI track. Was to extend Java's Track class.
 x MooNote      The functional representation of a MIDI note. Was to encompass the two MIDI events that constitute a note: NoteOn and NoteOff.
 
-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 [...].
+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 toolbart, the menu's popup dialogs 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 visualises 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.
 
@@ -40,6 +40,8 @@ As an indication of which classes that were most difficult to implement, the ver
 [...]
 
 Strictly graphical classes [...]
+Implementing the strictly graphical classes has at some points been both tricky, and boring. Probably beacuse of the programmers lack of experience of the Java Swing library. Huge amounts of time has been spended with trial and error. The Java Swing library offers rather inflexible layout managers, which sometimes can cause problems. This feature makes it real difficult to get a feeling of how the window actual will look onscreen, while implementing the classes.
+In retrospect it maybe should have been better if we chose to work only with the Java AWT library.
 ------------------------------
 2.5 Testing
 Är det nån som har testat nåt dårå?!?
@@ -67,6 +69,8 @@ This problem was especially unfortunate since it was the only performance aspect
 
 However, as we recently discovered, the Sun developers were also aware of this issue and, in trying to find a remedy for it, implemented some additional methods for controlling the viewport's visualisation during scrolling. This allowed us to reduce the time lag to a fraction.
 
+During our project some time has also been wasted when wrestling with Java Swing components showing up at the wrong position whith the wrong size. No matter how much we studied the API we could not find the answer of this problem. In the end we found out that rebooting our FreeBSD machines was the only cure to this problem. We suspect there is some kind of bug, either in the FreeBSD OS, or the windomaker application we use. After all, we never ran into this problem those rare times we were working on a Windows-platform
+
 The major changes and that not enough work design of the graphical classes resulted in that the different graphical classes couldn't be implemented on their own. Instead changes often had to take place in many different classes when some feature was added. This made the implementation slow, especially in the beginning, since there where many different ideas on how things should be implemented. This got better through time though, when the basic foundation was implemented it got easier to add the rest of the features.
 ------------------------------
 3. Conclusions