The Gart - Project report

Factulty of Computer Sciences
Østfold College

5 credits project
for graduate students

1. Preface
2. Introduction
3. Goals
4. Technology
1. Java
2. Code conventions
3. Linux
4. Web pages
5. CVS
6. UML
7. XML
8. Tools used
5. The Gart
6. Project work
1. Project plan
2. Project diary
3. Sourceforge, Open Source and GPL
7. Conclusion
8. User manual
1. Project dialog

2. Main screen

3. File menu

4. Preferences Window

5. Code views

6. Install notes

9. List of sources
10. Appendices
1. Pre project report
2. Features
3. Project meeting 30.08.2001
4. Project meeting 02.09.2001
5. Project meeting 03.09.2001
6. Project meeting 30.09.2001
7. Project meeting 11.12.2001
8. Hours used
9. Diary
10. Class diagram
11. CVS tree
12. Sequence diagram

4 - Tecnology

What is Java?
Java is a quite new object oriented programming language. It is developed by Sun Microsystems and was first initiated in January 1991. The Java compiler, written in Java, was introduced to the public in May 1995 and Netscape announces that they plan to support the new language in their browsers. In December the same year, it is clear that both Oracle and Microsoft will support Java in their products. From that day, Java's market share has only been increasing and the language has became popular by programmers all over the world.

The language itself tends to be compared to the older C++ language, due to both the similar syntax but also the object oriented nature of the language. However, Java is considered more secure and much easier to transport among platforms than its older colleague. This means that if you write a program in Java on the Mac platform, it can easily be ported to Windows or Unix with no or small modifications. In theory, a Java program can run on any platform that has a Java Virtual Machine, which includes HP-UX, AIX, Solaris, Linux, Mac, Windows and even Amiga. This is what Sun means when proclaiming "Write once - run everywhere". However, it should be mentioned that this is not completely true. Things especially like font, sound and video handling is quite different from platform to platform, and it still needs some work before Java appliations are fully cross platform compliant.

As previously stated, Java is similar to C++, but it has some advantages over its older rival. Firstly, as many programmers appreciate, Java has a garbage collector. This means that you don't have to keep track how which objects lie where in memory, and you don't have to remove them from memory once done with them. The garbage collector does all this work for you and makes programming much more relaxing.

If you are to learn Java, the natural place to start is Sun's official Java site, namely www.javasoft.com. There you'll find some good tutorials and the indispensable Java API doc. The language reference that every Java developer needs, even the most experienced Java programmer uses this on a daily basis. In addition to the JavaSoft website, we reccommend a good Java book to assist you in learning the langauge, such as Deitel's "Java Howto program". Secondly, because Java uses a virtual machine that functions as a layer between the compiled Java code and the operating system, parsing all commands from the Java program to OS specific calls, Java programmers can develop applications without thinking too much on the operating system it is intended to run on. Java can also be used on web pages in form of applets. These are Java programs that are linked to the HTML page with an <applet> or <object> tag. Furthermore, Java can be used to develop web applications using Java Server Pages and database connectivity is easy through the JDBC ( Java Dataase Connectivity ) classes.

Why did we use Java?
Java is by far the language we knew best at the time of project start. At Østfold College, Java is the language that receives the greates attention. After the first semester with Visual Basic, there are four compulsory courses that uses Java either as a tool or as the primary subject. We had used the language prior to the project for network programming, database interfacing, GUI designing and small scale game development. Thus we felt comfortable with using Java, although we knew we weren't gurus, we nevertheless wanted to learn more from this vast language and its enormous class library.

Because of the cross platform, open source nature of the project, it was also important to choose a widely available language that ran on multiple platforms. Java also has a clear syntax and strict naming and casting rules which is great when being multiple developers on the same project. Also, the settled conventions in java (thank you Sun) helps keeping the java code so clear and clean.

After Microsoft's introduction of C#, the all ready popular Java language where even further embrased by the open source community. C# is a proprietary platform dependent development language for the MS Windows platform.

We also considered using Python as an additonal language to Java. Python is well known for it's powerful string manipulation functions, which Java lacks. Due to loss in performance when executing Python from whithin Java, and based on advice from several Python/Java coders, we choose not to use Pyton. Some string manipulation functions where instead written by ourselves, found in GartHandyMan.

Soon after starting the project, we sat down to discuss the code convensions we would like to use in our project. Since we had programmed a lot on our own prior to the project, we all had our preferred ways of doing things. However, we saw it as a good thing that all code was written in the same way, so that there were fewer doubts when developing on our own and that code "meshed" easilier when put together.

Class names
All class names starts with "Gart", indicating that the class is part of the gart package. Interfaces starts with a "i" for "interface". After the first, capitalised letter, the classes also "starts" with a capitalised letter.

Methods
All methods start with small letters, as in the Java code convention, and the arguments are given as lower case letters, that are abbrevations of the object type. All words in the method name are captilised, except the first one, as stated above. E.g. "setNewComponent( String arr[][] )".

Whitespace and braces All parantheses are entered with a space at the beginning and at the end, e.g. ( an example ). Blocks are indented 3 spaces, and tabs are of course replaced with spaces (3 spaces). Start and end braces are written on the next line under the first letter of the statement or method/class decleration.

For example:

         public void setNewComponent( String arr[][] )
         {
               ...
         }
      

What is Linux?
Linux is an open source operating system running on a 32 bit architecture. Its origin is Unix, which is easy to spot when using the a Linux system. It has true multitasking, protected memory and is built for networking and multiple simultaneously logged on users. The core operating system, the kernel, is written in C and is maintained and updated by numerous contributing hackers around the world. Due to the open source nature of Linux, everyone can download it, view and modify the source, and of course, use it.

Linux has historically been used as a server OS, especially as the companion to the Apache web server, but also as a file server, database server and mail server. However, Linux has developed hugely the later years to become a worthy desktop alternative to Windows and Mac. Today, it is used even as gaming machine as several software houses, has begun shipping games on the Linux platform. However, Linux is first and foremost used on the desktop as the preferred OS of software developers. Preferred for its stability, scalability and easy system resources access.

For what did we use Linux and why? We have used Linux as the server OS for our CVS server. Furthermore, we have used Linux as our desktop OS for not just programming Java, but also for coding HTML, XML and CSS, designing with UML and creating illustrations for the various reports. However some development where done using Window 2000. Using Window made us aware of several multiplatform problems during the project evolution. Catching theese problems in an early stage of project period helped increase program robustness. Unfortunately we didn't have a Mac with JDK installed avalible and thus further testing of The Gart is needed on this OS.

As a server OS Linux was an obvious choice partly because of it's close relation to the open source community, but most of all for it's stability and relatively easy to use features.

Another reason for choosing Linux as a development platform is its speed and ease of reconfiguration, something that is greatly need when working on big Java programs. For instance, the JDK java compiler is much faster on Linux than the Windows version.

Furthermore, the three of us where fairly familiar with the Linux OS, how to install, configure and use it. And therefore it was easy to decide upon Linux as opposed to other unices. Not to mention that its license is free and that we have a lot of Linux competence at the College, if we were to run into problems. This was also the reason for choosing Debian Stable version 2.2r3.

The web is the place to promote our project and to communicate with the general public. Therefore it is important that the web pages are well made, easy to navigate and accessible to all people on the net.

The pages are coded in Emacs and are written after the XHTML 1.0 Strict specification from the World Wide Web Consortium ( W3C ). The W3C is an organisation that sets various standards on the Internet, such as XHTML, XML and CSS. We've done this for two reasons. Firstly, it's considered good craftsmanship to write code after the W3C recommendation, secondly by doing so, we ensure that the pages will be displayed as intended if the browser used to display them, has implemented the standards correctly.

We have also followed another standard put forth by the W3C, namely Cascading Style Sheets. Cascading Style Sheets, CSS for short, is a language for specifying the appearance of a markup document, such as HTML and XML. This separates the structure and presentation as intended by the W3C. All structure is put into the HTML document, whereas the presentation is described in the CSS file. This way, it's much easier to display the contents of a page appropriate to the device used for displaying the pages. Also, the use of CSS decreases the amount of code needed to make a website. Since all pages link to the same style sheet, the formatting information is only written in one file, instead of in every file. This way, it's easy to change e.g. the font on all pages, change it in one file and the change is applied to the whole site.

One great challenge when coding websites is to make them behave identical on the different browsers and platforms. Especially the Netscape 4 browser can be troublesome. We have spent some time to make the pages available to web surfer regardless of browser and platform. Our pages are displayed "correctly" on Mozilla, Netscape 4, Netscape 6, Opera, Lynx and Internet Explorer. The work on the Windows, the Mac and the Linux platform, they load fast and scale well to different screen sizes.

The website is decided in six sections, "news", "download", "documents", "diary", "contact us" and "home". The diary section is the one that has been updated the most. Every day we have worked with the project, we have entered a new entry to the diary, stating what we did do. This way, it has been easy for all interested in our project to be updated on the current developments on the project. Thus, giving our coordinator an easy way of follow our progression and spotting problems and stagnation under the way. The diary also has a link to our hours-used page where the three of us have added the hours used working on the project since june.

We have put a lot of information around our project on our site. Under the document and the download section, one could read about project meetings, class diagram and problems conserning the project as well as the actuall program and source code.

Concurrent Versions System is the Unix worlds eqvivalen to Microsoft's Visual SourceSafe. It is open source software that gives you version control on your files. It is based on using the commmand line, but it is also available with a Windows GUI.

The purpose of this piece of software is to prevent users to overwrite echothers work and have a means of tracing back changes to a file. All versions of all files are kept in the CVS repository and it is possible to retrace versions of the files and checkout these instead of the latest version, which is returned by default. CVS works by creating a "safe" where you put all source files of a program. The users of the CVS then checkout their own local copy of the repository to their home accounts. Changes to the code is then checked in to the "safe" and a change log is updated. If several users have modified the same files, these can be merged, or you can "lock" certain files, so that users don't get to change the one you are working with.

We have installed the CVS on gart.hiof.no and have checked out the code to our home areas at the workstations where we have done our work. This has given an extra dimension of security regarding our code, since the code has at all times resided at two machines.

We used CVS because we knew that we would be several people working on the project. We are familiar with the problems from previous programming projects we were familiar with the problems of overwriting files and version control. We found therefore CVS a great tool for providing us with version control of our source files. Furthermore, we found out that it wasn't just source code CVS was great for, so we soon included howto documents we had written, Java doc and shell scripts to the CVS tree. This way, could just do a cvs co gart to get all files related to the project, having to keep track of the different documents and scripts in order to work with the Gart project.

If gart.hiof.no is taken down, an updated cvs-repository shall publically available on gart.sourceforge.net, for to people who wants to keep developing the Gart.

What is UML?
First of all, UML is an abbreviation for Unified Modeling Language. As the name suggests, UML is an attempt to collect previous standard notations to one, common standard notation for modeling systems/programs.

In order to handle larger systems, it is vital to in some way model/design a plan on how the system is to function and how the different parts work together. Models can also be a nice helping hand to spot new classes, methods and variables that needs to be created or modified. The down side with different standards for notation is that one symbol easy can mean different things in different systems, and naturally this causes confusion and frustration among developers and project managers.

In addition to a collection of symbols, UML also defines a collection of diagrams in which the symbols can be used. There are diagrams where one can define the user's demands and needs towards the system, in addition to diagrams for stating various static and dynamic system behavior. Some diagrams, for example the component and class diagram are directly connected to the program code whereas other diagrams such as the usercase diagram and the sequence diagram only are meant as a help in the system development.

The nine diagrams defined by UML are as follows:

Activity diagrams
Use case diagrams
Deployment diagram

Class diagrams
Component diagrams
Object diagrams
Collaboration diagrams
Sequence diagrams
State chart diagrams

Of course, one can use the diagrams of choice, one is not committed to use all of them in order to follow the UML standard. In our project, we have chose to only use the class diagram

For a further description of UML, see the sources list.

Why we used UML
We soon realised that the project would grow very big. At least too big to that we could keep the overview of the system without any help, such as a graphical representation of the system. In other words, we didn't start hacking away at the system without first designing the system with the help of UML. This helped us greatly in spotting system implementation issues, such as interfaces, utilities and of course the backbone classes needed.

We live in an object oriented world and we strive at all times to follow the laws and joys of the community. Object oriented modeling is therefore, in addition to a necessity a natural way of here at Østfold College where we have compulsory course in "Modeling and System Development".

According to the UML model, the development process is user case driven, architecture focused and iterative. Object oriented analysis and design is about analysis of the problem, not how to implement the. The design is an expression for a solution of the problem: object oriented but programming language independent.

One of the advantages of this developing model, is that due to its usercase driven nature, it is always the user's needs that has the focus and drives the to excel. Not a single class should be added to the system if you can't prove that it supports of the usecases, thus keeping the focus on the user's needs. Another great thing about the UML model, the iterative nature of it. Each iteration in the system development should give a prototype of the system, the development team a chance to test the system at early stages of the development, spotting early in the process. These prototypes are also great to convince customers that system is moving in the right direction and gives them a good opportunity to give quality feedback the development phase.

Why we have used UML can be sumarised in these points:

Although a good UML diagram takes time to design, it makes things much easier when a system of this size.

A graphical representation of the system is a necessity when a system of this size.

The development process becomes more clear and precise. UML is a part of using a good architecture. With this we mean: simplicity, elegance, clarity, well formedness of course that we remain in the object oriented world.

eXtensible Markup Language

XML is powerful markup language that is a subset of SGML, just like its famous little brother HTML. Unlike HTML, XML is created for describing much more than just the of text and some pictures on a canvas. Therefore, one can define own elements and in XML and then make it up to the programming parsing the XML code what to do with the parsed.

The DTD, or Document Type Definition, is a file where you declare your different elements and entities. You then specify what they should contain and what they shouldn't. You then link your XML to your DTD to make the entered in the XML follow "your standards" stating in the DTD. This is exactly the same way it works when you write HTML pages. The DOCTYPE header specifies which DTD at W3C that determines what you can and you can't write in your HTML file, thus the different HTML versions, e.g. HTML 4.01 Transitional.

The aspect of XML in The Gart is a very important one. Although Java code generation the main objective of the program, XML is the format The Gart interacts with internally.

What we wanted to do, was to describe a Java GUI in the open format XML. This way, we would give a language independent description of a program GUI, something we believe is not yet done for Java GUI builders.

To accompany this, we made a parser for generate Java code from this XML representation of the GUI. Of course, Java code was what we wanted with this GUI building, but one immediate consequence of XML as a saving format, is that by making parsers that took the Gart XML and parsed it to other languages, our program could easily be a generic GUI builder and not just a Java tool.

The real challenge of using XML as a working format for the program, was to agree on the DTD design of the gartproject. At first, it all seemed pretty straight forward, but it soon came to us, that some issues needed to be dealt with in a more delicate way. We soon encountered cases where the layout of the DTD was far from obvious and we had many discussions on how to do it. After numerous revisions, we feel that we have agreed on a neat way of describing the GUI in XML.

The class that does the real XML handling is the GartXMLCrawler, residing in the gart.util package. It is used directly by the GartCodeGenerator and does what its name suggests: crawls DOM structures and returns the information requested.

Since XML handling was such an issue, and used to such a big extend in the program, we decided on seperating all the XML work in a seperate class, something which has worked very well for us.

Dia

The UML diagrams created to the project has been designed with the Dia program, which is a small application shipped with most Linux distributions. It was surprisingly easy to use and well equipped. We have used UML only to create a class diagram in order to get an overview of the classes used the project. It was early obvious that we need some sort of help to keep track of how the different classes worked and how the interacted and used each other. We did not use UML for anything else, such as diagrams or code generation, only class diagram for an overview, and for this task little Dia was more than sufficient.

Emacs

Emacs has been the program we've practically been living inside when working with the Gart project. This great, extensible programming editor is one of two big editors in the UNIX world. Written initially by Richard Stallman and released under the GPL, it is included on most distributions of Linux and can be found on all flavors of Unix. One of the remarkable things about the editor is the fact that it can be extended and modified with help of the Elisp programming language. This way, you can write elisp code to enhance the editor and customise it to meet actually your demands and needs. For example, to meet our Java code conventions, we had to write a little Elisp function to change the behavior of C mode in Emacs ( the mode used when editing Java files ).

     
         (defun my-c-mode-hook ()
            (setq c-basic-offset 3)
            (c-set-offset 'substatement-open 0))
         (add-hook 'c-mode-common-hook 'my-c-mode-hook)
      

We have used Emacs for Java programing, HTML, CSS, XML and DTD coding in addition to writing miscellaneous texts such as howtos and reports.

Java Development Kit

We have used Sun's Java Development Kit version 1.3 (JDK) as Java compiler, virtual machine and JavaDoc generator. All theese tools er familiar, an we had little problem using them.

The Gnu Image Manupulation Program

For different illustrations we used The Gimp. The Gimp is the Unix world's Adobe Photoshop and is surprisingly powerful. It is quite different to use, and it handles layers somewhat differently than Photoshop and Paint Shop Pro (familiar programs on the Windows platform), and we used therefore some time to figure it out. But once familiar with the interface and ways of doing things, The Gimp is fast and a reliable tool for creating graphics.

JPadPro

When not in Unix/Linux, the best alternative to Emacs is JPadPro. It is great for coding, and has many of the same shortcuts as Emacs, and even some others that are very practical.

<?xml version="1.0" encoding="UTF-16"?>
<!ELEMENT component (property*)>
<!ATTLIST component
   cast CDATA #REQUIRED
>
<!ELEMENT gartcomponents (package+)>
<!ELEMENT package (component+)>
<!ATTLIST package
   name CDATA #REQUIRED
>
<!ELEMENT property EMPTY>
<!ATTLIST property
   method CDATA #REQUIRED
   datatype CDATA #REQUIRED
>

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE gartcomponents SYSTEM "gartcomponents.dtd">
<gartcomponents>
   <package name="javax.swing">
      <component cast="JButton">
         <property method="Text" datatype="String"/>
         <property method="ToolTipText" datatype="String"/>
         <property method="DefaultCapable" datatype="boolean"/>
         <property method="Visible" datatype="boolean"/>
         <property method="Opaque" datatype="boolean"/>
      </component>
      <component cast="JLabel">
         <property method="Text" datatype="String"/>
         <property method="ToolTipText" datatype="String"/>
         <property method="Visible" datatype="boolean"/>
         <property method="Opaque" datatype="boolean"/>
      </component>
      .....
      .....
      .....

   </package>
   <package name="java.awt">
      <component cast="Button">
         <property method="Label" datatype="String"/>
      </component>
      <component cast="Label">
         <property method="Text" datatype="String"/>
      </component>
      <component cast="TextArea">
         <property method="Text" datatype="String"/>
      </component>
      <component cast="TextField">
         <property method="Text" datatype="String"/>
      </component>
      <component cast="Checkbox">
         <property method="Label" datatype="String"/>
         <property method="State" datatype="boolean"/>
      </component>
      .....
      .....
      .....

   </package>
   <package name="myclasses.mycomponents">
      <component cast="myButton">
         <property....../>
      </component>
      .....
      .....
      .....
   </package>    
</gartcomponents>

<?xml version="1.0" encoding="ISO-8859-1"?>
<gartproject type="applet">
   <component cast="JButton" name="" x="450" y="242" width="115" height="70" font="dialog.bold|1|12" background="204|204|204" foreground="102|102|153">
      <property method="Text" datatype="String" value="myButton"/>
      <property method="ToolTipText" datatype="String" value="Click here to be enlightenede..."/>
      <property method="DefaultCapable" datatype="boolean" value="false"/>
      <property method="Visible" datatype="boolean" value=""/>
      <property method="Opaque" datatype="boolean" value=""/>
   </component>
   <component cast="JTextArea" name="kjklø" x="192" y="157" width="115" height="70" font="dialog.bold|1|12" background="204|204|204" foreground="102|102|153">
      <property method="Text" datatype="String" value=""/>
      <property method="ToolTipText" datatype="String" value=""/>
      <property method="Visible" datatype="boolean" value=""/>
      <property method="Opaque" datatype="boolean" value=""/>
   </component>
</gartproject>

<?xml version="1.0" encoding="UTF-16"?>
<!ELEMENT component (property*)>
<!ELEMENT gartproject (component*)>
<!ATTLIST component
   cast CDATA #REQUIRED
   name CDATA #REQUIRED
   x CDATA #REQUIRED
   y CDATA #REQUIRED
   width CDATA #REQUIRED
   height CDATA #REQUIRED
   font CDATA #REQUIRED
   background CDATA #REQUIRED
   foreground CDATA #REQUIRED
>
<!ATTLIST gartproject
   type CDATA #REQUIRED
>
<!ELEMENT property EMPTY>
<!ATTLIST property
   method CDATA #REQUIRED
   datatype CDATA #REQUIRED
   value CDATA #REQUIRED
>

 
   arr[n][t]: String array with all the general properties.
              "n" indicates one property row.
              "t" can have values from 0 to 2.
 
   arr[n][2] contains the value of the property
   arr[n][1] contains the name of the corresponding set-method
   arr[n][0] contains the datatype. if a boolean do input through radiobuttons, otherwise textfields.

  
   an example:

   arr[0][0] = "String";
   arr[0][1] = "Text";
   arr[0][2] = "Press button to continue";
 
   arr[1][0] = "boolean";
   arr[1][1] = "Visible";
   arr[1][2] = "true";

   
   <property method="Text" datatype="String" value="Press button to continue"/>
   <property method="Visible" datatype="boolean" value="true"/>

    componentX.setText( "Press the button to continue" );
    componentX.setVisible( true );

    -GartToolBox parses gartcomponents.xml and gets initial properties for each component.
    -When an GartComponent is added it fetches this information from the toolbox (with new references of course)
    -When a GartComponent is singly selected, the GartPropertyWindow is notified, and dynamically rebuild corresponding to the
     property array of the selected component.

We decided eary in the project that all documents concerning the project would be public and avalible on the web site. In August we published the preproject report at gart.sourceforg.net. In the report we had set up five milestones for the project. No deadlines and and dates where specified, but we have continously during project meetings decided the pace and speed of the project progression. This have worked out fine and we feel we have reached our primary goal, to create an usable GUI design application for Java.

The five milestones where:

1.Research
Find resources on the net and consult fellow students and supervisor. There is alot happening on the GUI front of Java. Also, we need to spend some time to find out how to optimalise our code in order to make it run faster than standard Java applications, which are too slow. Byte compiling Java source, is in particular interesting and requires further investigation.

2.System analysis and design
Discussions on how the system is to both look and function, the so called "look and feel" of the program. It is important to do a thorough job here in order to get a mutual, clear view of the program objectives and how these are to be implemented.

Making sketches of the actual program GUI will also be important in order to make the software as easy to use as possible.

Several discussions need to be made in order to find out how the program is to parse different meta information, such as program configuration and flags in the Java code.

3.Implementation
Naturally, this will be a giant milestone. A natural start will be to make the GUI first in order the whole thing actually will look like, and it will thereby be easier to figure out how the program will function.

After getting the user interface to work, we will be working on the code generation from the layed out GUI components. When this works ( hopefully ), we will look at how to do this the other way, that is to generate a graphically representation of code previously generated by The Gart.

4.Testing
Testing is an essential an also a very important part of developing software, often overlooked by developers. We have already gotten voluntairy beta testers at the University of Trondheim, NTNU, and will also be needing the help from fellow students at our own faculty, at Østfold College in order to make our program as good as possible.

5.Documentation
Our intention is that the program shall be so user friendly that no documentation is needed. However, we will have help available both as a big document and as a functions within the program.

We started discussing the Gart already in June and deliverd a project application as soon as we had worked out what kind of project we wanted. In July we where away on summer vacation but we had the project in mind all summer. When we got back in August a lot of ideas and features had evolved during the summer and we where eager to get started.

A simple diary where set up and we have updated this log as often as possibleduring the project development. There are several advantages using a diary, it is usefull tokeep all the project mebers up to date on what have been done by who and when. The diary is also a valuable part of the project documentation and makes it possible to follow the development day by day.

The diary has a link to an hours used page, where each one of us have written down the hours spent on the project. The hours used page is mostly for our own use to see how much time we have used on the project, and making it easier to ajust project work to other school or work assignments.

Sourceforge.net is owned by Open Source Development Network, Inc. ("OSDN"). OSDN, the Open Source Development Network, is the leading news, collaboration and distribution community for IT and Open Source development, implementation and innovation. SourceForge.net's mission is to enrich the Open Source community by providing a centralized place for Open Source Developers to control and manage Open Source Software Development. ( source: www.sourceforge.net )

The Gart is an open source project, released under the GPL licence. In general this means that the source code is available to the public and that everyone can make changes to the code as long as they post their changes back to us. SourceForge is a site that has built up a huge open source community where everyone, either using or developing open source software, can take part. We signed up the Gart project and got accepted as a SourceForge project whithin a day. This meant that we got access to lots of features on the SourceForge site to help us developing and promoting the project. We have only used parts of the features available, because we have access to a local server, which works faster than the SourceForge server. Nevertheless, we will move our CVS repository to Sourceforge after the project has ended at the College, as we plan to continue developing The Gart in the future.

The Result

We have implemented an fully functional GUI creator for Java. While working on the Gart we often mentioned how convenient it would have been if the Gart was finished and could be used to implement the Gart. For this to be possible it had to fall throughe a time glimpse on the Internet. Unfortunately the was not the case and we had to strugle with the GUI problem one last time.

Besides using a lot of time on the Gart GUI we encouncured few problem that could not be solved either by workarounds or by the excellent bug databas at Sun's web site. We have put a lot of effort into making the program scalable and on most areas it is. The user can add his/hers own components by editing the XML-file. It is important to stake out that the Gart is a GUI and will not be able to

It was very satisfying to make a real, useful program for once. Most programs we make in our studies at Østfold College are for illistrating a point, testing a feature or aspect of programming, but not for being used for a real purpose. The Gart is what we have been hungering for: an application we are certain we will use in future Java projects.

We have encountered several cross platform challenges while doing a project this semester. For starters, we have discovered several differences in the Java implementation for Linux versus Windows. Once again, has Sun's slogan "Write once, run everywhere", proved itself to be untruthful. Especially is this true for different GUI issues and Java printing. The GUI problems has mostly to do with Frames and Swing components. It seems that its difficult to use Frames with Swing components on Windows, whereas the same application shows just fine on Linux. The problem was often that the apllication started allright, but it was scaled to 1x1 pixel (!) on one platform, whereas the same application scaled correctly to e.g. 500x500 on a different platform.

Another mysteerious problem to us, is the printing aspect of Java. The printing functionality in The Gart, is that the user can print the current Gart project's Java code to a printer of the user's choice. The printing module works just fine on Windows, but on Linux, nothing happens after selecting which printer to use. ( We used just 'lpr' as printer in Linux. This should use the default printer set up in /etc/printcap ).

Apart from the two themes: mixing Swing and Awt components and printing, there was little difference in the Java implementation on Windows and Linux. The Gart runs now happily on both the Microsoft and the GNU platforms.

A good thing that we have received throughout the project time is a great enthusiasm from fellow students, when they got a demonstration of the Gart. This great fellow studentship inspired us and made it easier to keep the steem up in throughout the semester.

It has been a great strength for the project that we have had both Linux and Windows developers on the team. This made the project process a great arena for disussing program design, and philosophy. We can conclude that what is obvious one world may be the quite oposite in another. It all comes down to perpspective and philosophy. Nevertheless, we feel that we have reached good design solutions, leaving The Gart both easy to use, yet advanced enough to be configurable and expandable to the user.

In the pre project report we mention that The Gart will run on Windows Linux and Mac. Unfortunately we have been unable to test The Gart on the Mac platform. We where familiar with both Windows and Linux, but sparsely knowledge conserning Mac and Java development. Searching the web we found that the new Mac OS X shippes with Java development support. We have Mac machines with OS 9.x avalible with only runtime enviroment 1.8 avalible and no development tools for Java, and thus we have been unable to test The Gart. From Mac newsgroups we learned that it is possible using workarounds and CodeWarrior to develop Java applications on Mac OS 8 and 9 but this was not recomended.

Although The Gart is a fully working program by the end of the project there are a few things we have in mind for further development. Since the program is highly scalable the Gart can without much trouble be expanded to support JPanels. It would be a nice feature to connect to the users favourite editor or be able to compile the Java code created in the gart. Theese are, however, features The Gart work perfectly well without.

JFrame

Click this button if you want to create a JFrame application. The JFrame template will be used for generating the framework for the Java code. The JFrame template is located in <gart-install-path>/templates/jframe.template and can be edited to suit your needs.

By default, it imports the needed libraries, such as swing, extends JFrame, implements ActionListener and supplies the common methods used when creating a JFrame. These methods includes a constructor, setupGUI() and adctionPerformed().

JApplet

Click this button if you want to create a JApplet application. The JApplet template will be used for generating the framework for the Java code. The JApplet template is located in <gart-install-path>/templates/japplet.template and can be edited to suit your needs.

By default, it imports the needed libraries, such as swing, extends JApplet, implements ActionListener and supplies the common methods used when creating a JApplet. These methods includes a constructor, init(), setupGUI() and adctionPerformed().

Applet

Click this button if you want to create a Applet application. The Applet template will be used for generating the framework for the Java code. The Applet template is located in <gart-install-path>/templates/applet.template and can be edited to suit your needs.

By default, it imports the needed libraries, such as java.Applet, extends Applet, implements ActionListener and supplies the common methods used when creating a Applet. These methods includes a constructor, init(), setupGUI() and adctionPerformed().

Frame

Click this button if you want to create a Frame application. The Frame template will be used for generating the framework for the Java code. The Frame template is located in <gart-install-path>/templates/frame.template and can be edited to suit your needs.

By default, it imports the needed libraries, such as swing, extends Frame, implements ActionListener and supplies the common methods used when creating a Frame. These methods includes a constructor, setupGUI() and adctionPerformed().

Custom Template

You can also use a template you have made yourself. These are Java files that are name filename.template and must reside in <gart-install-path>/templates/. They will then appear in the custom template combo box on the project dialog.

The only thing these templates must contain in order to work with The Gart, is two flags that will look like this:

   // <gart:global-variables>
   // </gart:global-variables>


   // <gart:setup-method> 
   private void setupGUI()
   {
   }
   // </gart:setup-method>
   

Apart from this, they can contain whatever you like, but The Gart will of course not guarantee that they will compile when you decide what to put in these templates.

Open Existing Project

Click here to open a Gart project that you have previously worked with.

These project files are really XML files written after the DTD located in <gart-install-path>/etc/gartprojcet.dtd and must be suffixed .gart in order to open them from the program.

It is however, possible to write the whole .gart file yourself manually, or adding blocks of code in your .gart file before opening them in The Gart. The Gart guarantees to understand your file, as long as it validates after the gartproject DTD.

Back to table of contents

Toolbox

On your left hand side, you will find the toolbox. This is where you select the different Java components you wish to add to your GUI.

The toolbox has different tabs with components that belong a specific package or group. By default, there are two tabs, Swing and Awt.

You may specify additional packages by editiong the <gart-install-path>/etc/gartcomponents.xml file. Be sure to validate it after the gartcomponents.dtd before loading The Gart anew. The DTD resides in <gart-install-path>/etc/ along with the other DTDs and setting files.

Toolbar

This is the icon bar above the canvas. Here you have access to most of the Gart functions such as New, Open, Save etc.

Note that you also have two cursor icons on the bar, number five and six from the right. The crosshair icon is for resizing and drawing GUI components, whereas the arrow is for selecting or moving components.

The Canvas

This is the main area of The Gart. It is where you compose your GUI.

Property window

This window is for setting the different visual properties of your Java components. When selecting a GUI component on the canvas, the coresponding properties will show in the property window.

Note that when no components are selected, the property window will just be gray.

Back to table of contents

   // <gart:global-variables>
   // </gart:global-variables>


   // <gart:setup-method> 
   private void setupGUI()
   {
   }
   // </gart:setup-method>
   

General

Here you can specify four elements. Show dialog, gart files path, java files path and path to your favorite editor.

Sow dialogs toggles if the user wants confirmation dialogs for selecting an application type at the project dialog.

The gart files path is the directory where you want to put all your Gart project files. The file chooser will go to this directory first, when issuing New, Open, Save and Save As requests to The Gart.

The gart files path is the directory where you want to put your Java files. The file chooser will go to this directory first, when issuing 'Import Java' and 'Export Java' commands to The Gart. The third path field is to your favoritet editor. This is of no sifinicans at the time being as this is not yet implemented in The Gart. However, in future versions, you will be given the option of viewing your code in your favorite editor instead of the Gart Viewer.

Code

This tab is for customising the way The Gart generates your Java code.

Indentation is how many spaces you want for each indentation, 3 is default.

Braces on next line, toggles if you want your open brace to go on the next line of each block statement.

Substatement offset is how many spaces you want for a substatement offset. This means additional indentation for the open brace in a code block. This is set by 0 by default.

   for( int i = 0; i < 10; i++ )
      {
         System.out.println( "This has substatement offset = 1" );
      }

The code settings will not affect the rest of the template you are using for generating Java code, only the code within the gart flags.

Canvas

Settings for the canvas, that is the biggest frame on the main screen in The Gart. You can set two things, if you want a visible grid, and if so, what grid type you want.

The grid types are listed in a combo box, and resides in the <gart-install-path>/canvases/ directory. These are simply big GIF images that are suitable for a GUI designing background. You may, of course, put any GIF picture you like, on your Gart backgorund.

Back to help screen

It is possible to view both the XML and Java code of your current Gart project. This functionality is accessed either by clicking on the Java and XML buttons on the toolbar or by selecting the Java and XML entries on the View menu, third menu option from the left.

There are four icons available in the viewer. These are, counting from the left, searching the document, printing the document, refreshing the content ( if something has changed on the Gart canvas ) and for closing the code view.

XML

An example on how the XML code of a Gart project looks in the GartViewer.

Java

An example on how the Java code of a Gart project looks in the GartViewer.

Search dialog

Both when viewing the XML and Java code, it is possible to search the code for a specific string. Just enter your query in the textfield and hit [ENTER] or click "Submit" to submit your query to the viewer.

If found, the text will be highlighted in the viewer. Note that there is a bug in the Java VM for Linux. You need to click the code view window and then click the search dialog again for this highlighting to work.

Back to table of contents

Linux

The user needs two files to install the gart: install.py and gart-1.0.tar.gz. The install script, install.py assumes that Python is installed on your system ( default on most Linux systems ), the user uses the Bash shell and that if already set, the CLASSPATH value is set with quotes. All these assumptions are based on default settings/configurations on most Linux systems.

         [shell_prompt$] python install_gart
      

It is also possible to do the install process manually: Extract the tarball gart-1.0.tar.gz and start the program with java gart.TheGart.
If you are jusing JDK 1.3 or lower, you need to extract the JAXP classes and the JAXP libraries to your CLASSPATH variable: jaxp.jar, crimson.jar and xalan.jar

         [shell_prompt$] tar xvzf gart-1.0.tar.gz -C /myinstall/directory
         [shell_prompt$] unzip /myinstall/directory/gart/bin/jaxp/jaxp-1.1.zip -d /myjaxpinstall/directory
         [shell_prompt$] emacs ~/.bashrc

         Add:
         JAXP="/myjaxpinstall/directory"
         export CLASSPATH="$CLASSPATH:.$JAXP/jaxp.jar:$JAXP/crimson.jar:$JAXP/xalan.jar"
         
         [shell_prompt$] cd /myinstall/directory/gart/source/
         [shell_prompt$] java gart.TheGart
      

The only thing the user needs in addition to these two files, is a Java VM, that should be installed on all systems where one wants to develop Java applications.

You supplied two setup.exe files. The one under the directory 'VM' contains an installation for users that does not have a java virtual machine (VM) installed ( Java Runtime Environment, JRE). We supply JRE 1.2.2_09 for Win32.

The setup.exe under the directory 'NoVM' is of course for users with VM already installed (NoVM means no VM in the setup package...). Most likely, users of this program both have JRE/VM, and most probably a version of JDK installed. Anyhow, the installation supplies you with rt.jar (runtime library for java), and crimson.jar/xalan.jar/jaxp.jar which are the jars needed for XML-handling. These are distributed with JDK 1.4, but not before this, and most users will not have these installed. Also the classpath, and the user.dir variable is set through the installation (really when InstallAnywhere runs our program through their environment lax.jar, this jar file is found under the installation directory).

This means that you can use this installation on a PC without any previous java-installations, and run The Gart. One thing should be mentioned though. We have used (the freeware version of) InstallAnywhere. InstallAnywhere somehow runs our program a bit different. This is probably because they run it through their "own java vm", lax.jar. A few minor bugs occurs, that is not present if you start the program right from the command line, instead of using the .exe-file from InstallAnywhere. Among these bugs are the generating of recent files list on the file menu, which messes up some indexes, before it has reached its maximum of 5 (five) recent files. Other bugs has not been present to us yet, but we suspect them of being there. Any bugs found when you start the program from the command line are our own fault though...

To start the program from the command line, make sure to set the classpath to the 'source' directory under the installation directory. This directory contains the whole Gart package structure with both source and class files. Also it contains rt.jar, xalan.jar, crimson.jar and jaxp.jar.

Sun's Java site:

• API documentation
• Bug database
• Discussion forums
• Java Developer Connection

JGuru
JPadPro

Linux

http://www.sourceforge.net
http://www.linux.com
http://www.redhat.com
http://www.debian.org

Apple

• http://www.apple.com/java

Emacs

The official Emacs site at GNU
Torstein Krause Johansen's Emacs pages

The ambition is to develop a GUI designer for Java.

The program is to be open source and 100% cross platform compliant, something that currently does not exist. Furthermore, it will be small, fast and easy to use with "hidden" power features, such as keyboard shortcuts for all operations.

The project is initially a 10 ECTS credits project at the Computer Science faculty of Østfold College, under supervision of professor Børre Stenseth. However, we hope that the project will be of interest to the open source community and that they will contribute with ideas and constructive criticism.

Currently, there are several big software vendors that deliver IDEs ( Integrated Development Environment ) that have a GUI designer ( such as Borland JBuilder and Sun Forte ). However, these programs are big, slow and are properitary software. Furthermore, they force the user to use their set of tools ( e.g. editor and debugger ) in order to develop Java programs.

We will therefore develop a program that only does the GUI design, is open source, and gives freedom in terms of choice of tools to be used. The code generated by The GUI Artist ( The Gart ) will be easy understandable and complient with code conventions used by the Gart project. The program will also feature reverse engineering of code previously generated by The Gart.

Project participants

Project group members

Håkon A. Jensen
hakon.a.jensen@hiof.no

Torstein Krause Johansen
torstein.k.johansen@hiof.no

Harald Tolleshaug
harald.tolleshaug@hiof.no

Project manager

Professor Børre Stenseth
borre.stenseth@hiof.no

Pre Project Phase

Hardware

Server hardware for setting up CVS ( Concurrent Versions System ) and websever. The CVS server is a great way of keeping version control of files when several people develop on the same project. It will also easen the work of retracing our steps when questions arise regarding the program progression. With a CVS server, it will also be easier to work with the project, wherever the participants may be.

An own webserver is also a great way of promoting the project that we hope and believe will be received with interest by the Java community.

The server will also function as a storage for our local copies of the CVS repository, easining the load on our own home accounts on the regular school servers.

Software

Due to the open source nature of our project, we chose to only use cross platform programming languages, open standards and open operating systems when developing the program.

Java will be our primary programming language during this project. CGI and maybe some program modules handling text parsing will implemented in Python. We will also use various Unix scripts for analysing various debug information.

Please note that although we develop and run our servers on Linux, the finished product will run on multiple platforms, alt least Windows, Linux and Mac.

Webpages Design and maintenance. Signed up at sourceforge and got full web hosting with CGI privileges and shell access. Our pages can now be viewed at gart.sourceforge.net.

Make project schedule

Agree on programming conventions

When several people are working on the same project, it is an advantage if everybody writes code in the same manner. After a short discussion on how to write Java code, we agreed on a 'programming standard'.

Find resources

The project will be heavily based on Java and thus, it will be necessary to research what is available, especially in terms of the graphic libraries ( such as java.awt, javax.swing ). Furthermore, it will be important to find out what is already available in the GUI design genre, what is good and what can be improved, in order to make our product a unique contribution to the Java community.

Milestones

Research

Find resources on the net and consult fellow students and supervisor. There is alot happening on the GUI front of Java. Also, we need to spend some time to find out how to optimalise our code in order to make it run faster than standard Java applications, which are too slow. Byte compiling Java source, is in particular interesting and requires further investigation.

System analysis and design

Discussions on how the system is to both look and function, the so called "look and feel" of the program. It is important to do a thorough job here in order to get a mutual, clear view of the program objectives and how these are to be implemented.

Making sketches of the actual program GUI will also be important in order to make the software as easy to use as possible.

Several discussions need to be made in order to find out how the program is to parse different meta information, such as program configuration and flags in the Java code.

Implementation

Naturally, this will be a giant milestone. A natural start will be to make the GUI first in order the whole thing actually will look like, and it will thereby be easier to figure out how the program will function.

After getting the user interface to work, we will be working on the code generation from the layed out GUI components. When this works ( hopefully ), we will look at how to do this the other way, that is to generate a graphically representation of code previously generated by The Gart.

Testing

Testing is an essential an also a very important part of developing software, often overlooked by developers. We have already gotten voluntairy beta testers at the University of Trondheim, NTNU, and will also be needing the help from fellow students at our own faculty, at Østfold College in order to make our program as good as possible.

Documentation

Our intention is that the program shall be so user friendly that no documentation is needed. However, we will have help available both as a big document and as a functions within the program.

Project Finish

We hope to have the program finished by the time we reach the middle of December 2001. However, it is perfectly alright for others to participate in the project with ideas or corrections or to develop it to suit others' needs, as long as the report their changes to the code back to use ( all of this in accordance with the GPL licence ).

Project Responsibilities

Since we are only three group members, we must both work on all the different components of the project. However, this may be subject to change. But how we will solve this, is yet to be decided.

How It Will Work

When starting the program, the user will be promptet for what kind of application he/she wants to develop, either Java Frame, Java Console, or Java Applet. These three choice can again be chosen with or with the Swing graphical components.

The user will then be sent to the main design view, where he or she can add, remove, resize, move and change visual properties of different graphics components.

Code can then be generated with the click of a button and the the result viewed from within The Gart. It will also be possible to go the other way. I.e. to view GUI from code previously generated The Gart, so called reverse engineering.

There are also some things that may be implemented in the program, such as invoking standard editor for actually viewing and modifying the code, viewing online documentation in web browser and printing ( this will be platform dependent ).

This is a list of features in The Gart. All the features are ordered by priority. 1st priority features are vital parts of The Gart and will be implemented, while 2nd priority features migth be included during the project evolution.

The Gart will use XML for representing which graphic components will be available, for configuration of the Gart, for representation of the GUI (made in Gart), and the user's preferences.

Reverse engineering of java code generated by The Gart. The Gart will always work on a XML representation of the GUI, and will feature parsers for xml2java, and java2xml.

The Gart will generate a java file, with flags defining code-parts, which are Gart dependent. A java file can be reversly engineered, but only code parts within flags will be extracted, and updated in the java file. This means that you can come back to Gart (import your java file) and add to/update the GUI without affecting the rest of your java code. The java file will then work as a template for The Gart, and a new xml representation of your GUI is generated. This can be illustrated:

1^st priority

• The Gart supports Frame, JFrame, Applet and JApplet.
• Supports only null layout.
• Supports java.awt and javax.swing graphic components.
• java.awt:
• Button
• Checkbox
• Choice
• Image
• Label
• List
• ScrollBar
• ScrollPane
<
• TextArea
• TextField
• javax.swing
• ImageIcon
• JButton
• JCheckBox
• JComboBox
• JEditorPane
• JLabel
• JList
• JRadioButton
• JScrollPane
• JSlider
• JTable
• JTextArea
• JTextField
• JTextPane
• Drag 'n drop.
• Resizing objects.
• Expert mode with keyboard shortcuts and code window.
• Generate java code from GUI.
• Complete XML presentation of the GUI.
• All configuration files written in XML.
• The Gart will run satifactory on Linux and Windows.
• Setting visual properties on graphical components, such as x and y coordinates, color, font type, font size, width and height, caption and variable name.
• Automatic adding of ActionListener, actionPerformed method and import statement for java.io.event.

2^nd priority

• java.awt:
• Panel
• javax.swing:
• JPanel
• The Gart will run on Mac
• Reverse engineering of code not generated by The Gart, given that it uses null layout
• Connectivity between The Gart and standard editor.

The Gart will not:

• Be a tool for programming java ( but for designing GUI for java ).
• Be shipped with the MicroSoft Visual Studio package
• Help out with your sex life

• Attendants:
• Børre Stenseth
• Torstein Krause Johansen
• Håkon A. Jensen

We discussed the features of The Gart, their importance and how to implement them. Børre Stenseth made us aware of a few problems that might occure later on in the project. Here's a list of what we discussed.

• The Gart will run under both MS Windows and Linux.
• The visibility of components placed on top of each other. Does the GUI components need a visibility rank propertie?
• How to start the default editor in both Windows and Linux.
• Do we have to use the swing classes or can we entierly rely on java 1.1 and awt.
• How to execute python-files from Java.
• How to set the classpath in The Gart.
• How to link exsisting java code with a Gart GUI.

• Attendants:
• Torstein Krause Johansen
• Håkon A. Jensen
• Harald Tolleshaug

All project member presented their status. Torstein had worked on GartProjectDialog, GartViewer, GartPreferencesWindow, GartFileHandler and various connection between these classes.

Harald had been working the framework for the GartFooBar. GartCanvas and GartComponent have increasing functionality and will soon be finished. The main worry right now is some mystical behavior in the GartComponent.

Håkon have been fighting with the GartPropertyWindow. He is working on getting generic use of the functions handling incoming String arrays of GartComponent properties and the presentation of these properties.

The Road Ahead

We discussed the timeline ahead. When we are to finish the implementattion of the first Gart prototype. Without code parsing and generation. This is to be accomplished by the end of week 42.

We agreed to divide the work as follows:

• Torstein is to tie the main program logic together. That is, making TheGart.java work together with GartProjectDialog, GartProject, GartGUI, GartFooBar etc.
• Harald and Håkon are to finish their work on GartCanvas, GartComponent, GartToolBox and GartPropertyWindow and make these classes work together.

We agreed on some program design issues, especially that the GartProject is to be a quite thin class, solely calling methods in other classes and only storing information unique to the current project.

• Attendants:
• Børre Stenseth
• Harald Tolleshaug
• Torstein Krause Johansen
• Håkon A. Jensen

Since our last meeting many of the GUI classes have been implemented, but the heavy logic remains to be done. Here is a list of what we discussed.

• Which flaggs are needed to generated reversible java code. Is the import java function usefull if it only imports code generated by The Gart?
• The gererated java code will contain the name of XML file used to gererate it.
• In the XML presentation of the GUI:
• Are elements or atributes most convenient to represent the various java GUI components.
• Will the XML file size affect the speed of The Gart.
• The GUI will be up and running within week 42.
• Harald presented a problem with setBounds(..) and mouse event. The component somehow fails to resize.
• Torstein has problems with setSize(..) and JFrame on the Linux platform. It works with Frame.
• Is it possible, without much troble, to use the java components instead of just labels to represent the GUI in The Gart.

• Attendants:
• Glenn Ole Hellekjær
• Torstein Krause Johansen
• Håkon A. Jensen

Introduction

Hellekjær is one of the few Mac users at Østfold College and we hoped he could give us some answers conserning Mac and Java development, as well as give us an introduction to the Mac world.

Since Hellekjær works at the faculty for English at Østfold College, he has little knowledge of what Java developers need. Never the less he is an expert in using Mac.

Summary

We ( Torstein and Håkon ) got an introduction to how Mac users work and how the window system is buildt up. Hellekjær downloaded a program and showed us how easy it is to install new applications on Mac.

He told us that after using Mac OS X for a while he went back to OS 9.1 because OS X still lacks support for numerous applications.

We also tried to download and install jdk for Mac, but was unable to find jdk for classic Mac OS. One of the biggest differences we found between Windows, Linux and Mac is the absens of a text console on Mac.

We decided to look further into the Mac java bit later on during the project development.

• Attendants:
• Harald Tolleshaug
• Torstein Krause Johansen
• Håkon A. Jensen

Torstein and Harald presented their latest development on The Gart. Håkon was back from his exams and got updated on The Gart's progression.

With only a week left of the project a list of todos was written down:

• Customizable canvas background
• Import of self made user packages to iGartComponents
• GartPropertyWindow: Remove general font/color property
• GartCanvas: Implement align vertical/horisontal util
• Remove PanelProperties from GartPropertyWindow
• Menu:Implement Save as...
• Menu: "Close" gets the same function as "New"
• Preferences gart/java path
• Export of java files

A deadline for finishing java coding was set to wednesday 12th. The remaing time is dedicated to the project rapport and documentation of The Gart.

Harald Tolleshaug

Thursday   30.08.2001 3   hours
Friday     31.08.2001 6.5 hours

Tuesday    04.09.2001 4   hours
Wednesday  05.09.2001 5   hours
Friday     07.09.2001 7.5 hours

Tuesday    11.09.2001 5   hours
Wednesday  12.09.2001 5   hours
Friday     14.09.2001 6   hours

Monday     17.09.2001 1,5 hours
Tuesday    18.09.2001 6   hours
Wednesday  19.09.2001 5   hours
Friday     21.09.2001 7   hours

Tuesday    25.09.2001 9   hours
Wednesday  26.09.2001 5   hours
Friday     28.09.2001 7   hours

Tuesday    02.10.2001 8   hours
Wednesday  03.10.2001 5   hours
Friday     05.10.2001 3   hours

Monday     08.10.2001 4   hours
Tuesday    09.10.2001 5   hours
Wednesday  10.10.2001 3   hours
Friday     12.10.2001 3   hours

Monday     15.10.2001 2   hours
Tuesday    16.10.2001 6   hours
Wednesday  17.10.2001 5   hours
Thursday   18.10.2001 2   hours
Friday     19.10.2001 5   hours

Monday     22.10.2001 1   hours
Tuesday    23.10.2001 7   hours
Wednesday  24.10.2001 5   hours

And then came the flu...

Saturday   03.11.2001 4   hours

Tuesday    06.11.2001 5   hours
Wednesday  07.11.2001 2   hours
Thursday   08.11.2001 2   hours
Friday     09.11.2001 3   hours

Monday     12.11.2001 3   hours
Tuesday    13.11.2001 5   hours
Wednesday  14.11.2001 2   hours
Friday     16.11.2001 7   hours

Tuesday    27.11.2001 11  hours
Wednesday  28.11.2001 9   hours
Friday     30.11.2001 10  hours

Monday     03.12.2001 8   hours
Tuesday    04.12.2001 6   hours
Wednesday  05.12.2001 8,5 hours
Thursday   06.12.2001 7   hours
Friday     07.12.2001 6,5 hours
Sunday     09.12.2001 3   hours

Monday     10.12.2001 11  hours
Tuesday    11.12.2001 6   hours
Wednesday  12.12.2001 8   hours
Thursday   13.12.2001 7   hours
Friday     14.12.2001 9   hours
Saturday   15.12.2001 2,5 hours

Håkon A. Jensen

Monday    13.08.2001 4   hours

Monday    27.08.2001 6   hours
Tuesday   28.08.2001 5   hours
Wednesday 29.08.2001 5.5 hours
Thursday  30.08.2001 3   hours
Friday    31.08.2001 7.5 hours

Tuesday   05.09.2001 5   hours
Wednesday 06.09.2001 4   hours
Friday    07.09.2001 7.5 hours

Tuesday   11.09.2001 5   hours
Wednesday 12.09.2001 7   hours
Friday    14.09.2001 6.5 hours

Tuesday   18.09.2001 6   hours
Wednesday 19.09.2001 5   hours
Friday    21.09.2001 6   hours

Tuesday   02.10.2001 2   hours
Wednesday 03.10.2001 5   hours
Friday    05.10.2001 4   hours
Saturday  06.10.2001 2   hours

Monday    08.10.2001 2   hours
Tuesday   09.10.2001 3   hours
Wednesday 10.10.2001 4   hours
Friday    12.10.2001 7   hours
Saturday  13.10.2001 2   hours 
Sunday    14.10.2001 1.5 hours

Monday    15.10.2001 4   hours
Tuesday   16.10.2001 4   hours
Wednesday 17.10.2001 4   hours
Friday    19.10.2001 7   hours

Tuesday   23.10.2001 3   hours
Wednesday 24.10.2001 1   hours

Tuesday   30.10.2001 4   hours
Wednesday 31.10.2001 5   hours

Tuesday   06.11.2001 5   hours
Wednesday 07.11.2001 2   hours
Friday    09.11.2001 3   hours

Tuesday   13.11.2001 5   hours
Wednesday 14.11.2001 2   hours
Friday    16.11.2001 7   hours

Tuesday   20.11.2001 3   hours
Wednesday 21.11.2001 4   hours

Tuesday   27.11.2001 11  hours
Friday    30.11.2001 5   hours

Studying for my exams.

Tuesday    11.12.2001 1   hours
Wednesday  12.12.2001 10  hours
Thursday   13.12.2001 8   hours
Friday     14.12.2001 7   hours
Saturday   15.12.2001 7   hours

Torstein Krause Johansen

Monday    13.08.2001 4   hours

Monday    27.08.2001 5   hours
Tuesday   28.08.2001 5   hours
Wednesday 29.08.2001 5.5 hours
Thursday  30.08.2001 3   hours
Friday    31.08.2001 6.5 hours

Tuesday   04.09.2001 7   hours
Wednesday 05.09.2001 5,5 hours
Friday    07.09.2001 7.5 hours

Tuesday   11.09.2001 5   hours
Wednesday 12.09.2001 8   hours
Friday    14.09.2001 6.5 hours

Tuesday   18.09.2001 6   hours
Wednesday 19.09.2001 8   hours
Friday    21.09.2001 7   hours

Thursday  27.09.2001 3   hours
Sunday    30.09.2001 3   hours

Tuesday   02.10.2001 3   hours
Wednesday 03.10.2001 3   hours
Friday    05.10.2001 3   hours
Saturday  06.10.2001 4   hours
Sunday    07.10.2001 4   hours

Tuesday   09.10.2001 1   hour
Wednesday 10.10.2001 3   hours
Friday    12.10.2001 7   hours

Tuesday   16.10.2001 6   hours
Wednesday 17.10.2001 6   hours

Tuesday   23.10.2001 8   hours
Wednesday 24.10.2001 1   hour

Tuesday   30.10.2001 5   hours
Wednesday 31.10.2001 3   hours
Friday    02.11.2001 6   hours

Tuesday   13.11.2001 4   hours
Wednesday 14.11.2001 10  hours

Wednesday 21.11.2001 5   hours
Saturday  24.11.2001 2.5 hours

Tuesday   27.11.2001 7   hours
Wednesday 29.11.2001 8   hours
Friday    30.11.2001 6.5 hours
Sunday    02.12.2001 6   hours

Tuesday   04.12.2001 9   hours
Wednesday 05.12.2001 8.5 hours
Friday    07.12.2001 7   hours
Saturday  08.12.2001 4.5 hours
Sunday    09.12.2001 4   hours

Monday    10.12.2001 6   hours
Tuesday   11.12.2001 6   hours
Wednesday 12.12.2001 11  hours
Thursday  13.12.2001 8   hours
Friday    14.12.2001 7.5 hours
Saturday  15.12.2001 4   hours
Sunday    16.12.2001 10  hours

Monday    17.12.2001 5.5 hours

List of hours used on the project

gart/
   source/

      gart/
         TheGart.java

         util/
            GartCloseWindowAndExit.java
            GartCodeGenerator.java
            GartCodeParser.java
            GartConfigurator.java
            GartComponentProperties.java
            GartFileHandler.java
            GartFilter.java
            GartHandyMan.java
            GartGenericFilter.java
            GartJavaFilter.java
            GartSTATICVARS.java
            iGartCanvasMessenger.java
            iGartConfig.java
            iGartFontMessenger.java
            iGartGUI.java
            iGartMainMessenger.java
            iGartPropertyMessenger.java
            iGartSearch.java
            iGartToolboxMessenger.java
            iGartViewerMessenger.java

         gui/
            GartFontSelection.java
            GartFooBar.java
            GartGUI.java
            GartGUIComponent.java
            GartPreferencesWindow.java
            GartProjectDialog.java
            GartPropertyWindow.java
            GartSearchDialog.java
            GartSubSplitPane.java
            GartToolbar.java            
            GartToolbox.java
            GartViewer.java

         exception/
            GartException.java

         session/
            GartProject.java
            GartComponent.java
            GartCanvas.java

   uml/
      gart.uml
      gart.png
      xml_properties_toolbox_canvas

   etc/
      gartconfig.xml
      gartcomponents.xml
      gartconfig.dtd
      gartcomponents.dtd
      gartguirepresentation.dtd

   bin/
      compile_gart.sh
      gart_javadoc.sh

      jde/
         install_jde.sh
         jde_packages.tar.gz
     
      jaxp/
         installl_jaxp.sh
         jaxp-1.1.zip

   doc/
      cvs_howto
      
      garthelp/
         about.html

      javadoc/
  
   canvases/
      dots_gray.gif
      dots_white.gif
      grid_gray.gif
      grid_white.gif

   templates/
      applet.template
      frame.template
      japplet.template
      jframe.template

Sequence diagram