Second Assignment

Be ready for Jurassic Park 3 : let's build FSN, a File System Navigator

In Jurassic Park One, the little heroine used a 3D graphical interface to UNIX to ask for the closing of a door. This assignment is about creating the same interface in Java (without the dinosaurs !). The original stuff was done by Silicon Graphics (SGI) some years ago (a couple of year before Jurassic Park).

Original FSN

As seen in "Jurassic Park"!

FSN (pronounced fusion) is a file system navigator in cyberspace. It lays out the directories in a hierarchy with each directory represented by a pedestal. The height of the pedestal is proportional to the size of the files in the directory. The directories are connected by wires, on which it is possible to travel. On top of each directory are boxes representing individual files. The height of the box represents the size of the file, while the colour represents the age.
FSN is intended as an investigation in information landscape navigation. Although the file system was chosen as a system to navigate through, similar paradigms could be applied to other trees and graphs, such as call graphs.
Keep in mind that FSN is a prototype and an experiment. It is neither a full featured product nor a replacement for a filesystem manager such as Workspace.

Developed under IRIX 4.0.1+, FSN (pronounced fusion) is a cyberspace rendering of a file system. It uses the hierarchical nature of the data to render each directory as a pedestal. The height of the pedestal represents the number of files in the directory. On top of each directory are boxes representing the individual files. Again, the height of the box is used to denote the size of the file. Colour is also used in the visualisation to indicate the age of the files. Figure 3.1 shows a screenshot of the FSN system.

The user can move around the visualisation to gain different views on the data; this prevents a large directory obscuring the user's view of smaller directories. Access can be gained to the actual files by clicking on the boxes representing them. The spatial layout of the pedestals and files represents the hierarchy of the file system, and is designed to ensure that there is no overlap of directories which might cause problems of occlusion.

Although based on the file system, the information landscape could be modified to represent other graph or tree structures. The visualisation is fairly static and only information on size and age is used to distinguish between the different files and directories. This does have the benefit of a consistent mapping which the user will become familiar with over time.

Clic on the icon to get a larger view


The Assignment version of FSN

The information collector / Tree generator

Before building a 3D landscape of a tree of data, you first need to get that tree of data. Based on the command line arguments or from the GUI one, you need to explore recursively a File System Hierarchy from a given directory. You will collect information about the files and subdirectories contain in the directory like name, number of file, size, age, type... In order to limit the complexity of the scene, two other arguments are proposed : the max. number of files to scan and the max. number of levels of the hierarchy to explore (see point 3 of the minimum requirements). Not that you will not follow symbolic links.

The landscape

The landscape is composed of three sorts of shape : the directory building cubes, the links between the directories and the files cubes on top of the directories.

Each directory is represented by a pedestal. The height of the pedestal is proportional to the total size of the files in the directory, it surface, to the number of files. The directories are connected by wires or links, on which it is possible to travel. On top of each directory are boxes representing individual files. The height of the box represents the size of the file, while the colour represents the age. On top of each box is a little picto (a texture image) that represent the type of file within a simplified classification.

You will have to think a bit about the way to size and place correctly every directory in such a way that they do not overlap each other and that each level is aligned (the front border of each pedestal of a given hierarchy level are placed on the same line).

The interface

two metaphors : the flying saucer and superman

the flying saucer

You should be able to move forward and backward, left and right by using the arrow keys. The pitch and the height of the viewpoint should be change with buttons or slider of the Swing interface.


You should be able to clic on a subdirectory building or on the link that connect it to its father. Then you will fly softly (interpolator) from your current viewpoint to the one located in front of the selected directory. At every moment it should be possible to go back to the father directory of the last pointed jump with a button"back". If no jump has yet been done (only flying saucer moves), the back button will bring you back to the entry point (in front of the first directory).

When moving the mouse on a link or a directory building, the name of the directory should be displayed.

When you are located in front of a directory, and you point your mouse to a file in that directory (local behaviour limited to the neighbourhood of that directory), you should get textual information summary about that file (name, volume, type, age, owner, group owner, right...)

Ground Rules for all projects:

To submit a project...

you should put altogether, in a directory called A2_UstudentID1_UstudentID2

(Where 'studentID1'... your student ID !)

Use the jar command to put your directory into a single jar file based on the same name and mail this file to

cd .. (go to the directory in which your A2_UstudentID1_UstudentID2 is located)
jar cvf A2_UstudentID1_UstudentID2.jar A2_UstudentID1_UstudentID2/

Mail the file (A2_UstudentID1_UstudentID2.jar) as a attached document. Be sure that the title of your mail is 'CGA2:A2_UstudentID1_UstudentID2.jar'

The minimum requirements

Your project should be composed of, at least, the following :

(1) A set of at least 4 to 6 well balanced classes. Think about it in term of reusability of the code, and parcelling of the work between members of the working group. You could for instance have a class File3D that would extend Java File Class.

(2) One public class, whose name will be "Assignment" and that will contain the "main method" in such a way that, to test your project, I will only need to call 'java Assignment [command line arguments]' to run it. Because yours classes will be well documented, I should be able to write that "Assignment" class by myself without to much work. That means that the aim of that class is just to get and treat the command line arguments and launch the main one(s).

(3) You will explain the use of the arguments in your README file but the three first one will be directoryPath maxDepthExploration maxNumberOfFile

the arguments are optional (for the user, not for the implementation !)

directoryPath is the path of the directory that will be scanned. The default value is the current directory (the one from which the program is run)

maxDepthExploration is the depth of the subdirectory exploration. '0' would mean that you would display : the main directory as a cube, its file on the cube and the subdirectories as a set of cubes behind the main one, but without any files on them. The default value is no limitation in depth (you get the same behaviour with a negative value for maxDepthExploration).

maxNumberOfFile the maximum number of file to analyse. Once you reach that number, you keep analysing the files of the directory in which that event has occurred, but stop the analyse at that directory. The default value is given by a well documented constant in your implementation.

Each time you have to stop the analyse of a tree, be sure to get at least the size and the number of elements contained by the directories that will not be scanned, in order to display a well scaled cube to represent that directory. The aim of theses limitations is not do do less scanning, but to get a not too complex scene to display.

E.g. : java Assignment /users 3 500

or java Assignment ./subDir 2

As this assignment deal with directory path names, it would be a good idea to check your code both on windows and Linux platform and to use methods of the class File

(4) Remember that sometime, users may be dumb and may not use the right number of argument, nor the expected argument

(5) Your main classes should not have references to the com.sun.j3d.utils package. If you really want to use theses packages, you should encapsulate their use into some of your specific classes. You will then be able to use your personal specific classes into your main classes

(6) the usual comfort of an interface is the resizability of the main frame and the fact that the frame is well dimensioned and placed inside the display screen at the start.

(7) The scene should contain a background object and a horizontal plane.

(8) Your code should be well commented (extracted comment for the documentation and some inside comment whenever there is some algorithm to comment.

Optional stuff that will impress and that are not totally optional :

You should do at least two ( yes 2 ) of theses options to get the maximum mark.