-->

Java Dot Plot

I'm trying to teach my eldest son Java from scratch using some tutorials forund on the web. He knows nothing about programming so it is an interesting, though slow, process. To make sure I am not leading him too far astray I'll have to do some Java programming of my own. The obvious choice is to reimplement DotPlot in Java.

I want to see if I can do a rigorous TestFirst implementation. Unfortunately I know so little about the JUnit tools that it might take a while. Wish me luck!

As I am using BlueJ to teach Justin I thought I'd use it myself. Go to UsingBluej for the occasional odd scribbles that come to mind as I go along.

Well BlueJ is alright but I want to understand the details so back to basics with Emacs and Ant in LearningJava.

Dot Plotter Specification

More of a ramble through a possible feature list really. Anyway I like to get a statement of the grand plan down first however vague it might be and then implement something much simpler and easier using the grand plan as inspiration. So here goes:

• must be able to plot an abritrary number of files,
• the file selections must be persistent,
• the file selection criteria must be persistent,
• the criteria must include things like file globs in one folder, file globs in a tree, file globs in an arbitrary number of folders (different globs in each), multiple globs in the same folder, regukar expression matching, include and exclude criteria.
• tokenising must be user defineable or at least a reasonable variety of rules must be provided.
• tokenising must be language aware; what constitutes a separator in one language may be a significant token in another,
• the application must be able to show the content of the files that corresponds to a displayed coordinate on the dotplot,
• scrolling in the files should move a cross hair on the dot plot,
• the user interface should present the list of files so that the user can quickly navigate to an area of interest,
• must be able to zoom the plot,
• when the plot is zoomed then scrolling in the file display should pan the plot,
• the user must be able to save the state of the session so that a time consuming plot does not need to be recalculated,
• the plot must be exportable

Even I could go on adding ideas and enlarging on these for pages but I think that is enough to give me a grand and distant goal. So now a few notes about some possible implications of these goals:

File selection

this should occur outside the plotter proper so that the plotter takes a list of files or file names and doesn't need to worry about where they came from. This gives an opportunity to create a simple selector to begin with and create fancier ones later.

Tokenising

I don't know how complex this could be but there are certainly several different ways to do it. Again this should be isolated from the plotter so that the plotter simply asks someone for a token and gets it without caring what the interpretation of whitespace, commas, brackets and so on might be.

Synchronisation with file contents

this means that there must be a mechanism that translates a coordinate in the dot plot display into a filename and character offset.

Zooming

remember that a program of ten files of a thousand lines each might have twenty thousand tokens and that that is the size of the side of the dotplot this means that if the display is a thousand pixels square that one pixel on the plot will correspond to about four hundred tokens (20x20). Such a program is not by any means large so we will certainly need facilities for panning and zooming.

File lists

obviously this means that we must hold on to the list of files and be able to present it to the user. But more than that it means that we have to be able to organise it because there can easily be hundreds of files in a dotplot. This suggests that more innovative ways will be needed to display and persist the plots because they will certainly be time consuming to produce.

---

Updated: 2004-01-29

Index