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.