[Jtreeview-devel] The Future of Java Treeview development

[Alok S. <al...@ca...>]

Hello all,

I thank you all for your contributions, and I think Java Treeview is a 
useful piece of software with a bright future because of them. However, 
as java treeview becomes more mature, you are using it in very 
different ways. There seems to be increasing opportunity for changes to 
conflict. Imposing some order to minimize conflicts is the purpose of 
this email.

In particular,

1) I would like to put everyone that this email is addressed to on the 
jtreeview-devel list (except those already on it) and keep most of the 
development talk on that list so that you can keep abreast  of changes 
that may impact you. I realize that we all get way too much email 
already, but you can always delete them when they are irrelevant. also, 
it will all be archived. I would like to be clear that unless I hear 
otherwise, I plan to sign you up for this list.

2) I think we should try to come up with a fairly comprehensive set of 
test cases. This can simply be driven by things that go wrong, and 
slowly accrete as time goes by. Here's what I currently do before each 
build:

- ensure that all examples from the website load and display all views 
properly
- ensure that the applet version loads and displays files properly
- ensure that k-means files load properly.
- try doing a find, and then generating a summary view.

I don't want to drag anyone's feet over the coals, but the above was 
sufficient to catch notable bugs in code that was submitted to me. For 
instance, the TextView was redone so that each column of annotations 
gets its own frame and scrollbar  by adding a TextViewManager, which is 
a subclass of ModelView. Unfortunately, TextViewManager that didn't not 
propagate setViewFrame() to all the TextViews it manages, and so was a 
badly flawed implementation of ModelView that led to some weird 
behavior in the test suite. As a second example, when the file loading 
was redone to reduce memory load,  a row count bug was introduced that 
caused off-by-one errors in the display of certain, but not all files.

It's impossible to read through 1000 lines of code and find these bugs, 
we need a good, hopefully automated, test suite. The current test suite 
is far from comprehensive (for instance, I don't test export at all), 
so you may want to think of some new tests to add that are specific to 
functionality that is important to you. I had to do all above testing 
by hand, which is really tedious, and will get even more so as more 
tests are added. We should probably try to find ways to automate 
testing. Anyone do this before? Is JUnit any good? Automated test 
suggestions accompanied by code would be ideal. In the meantime, I will 
just put together a web page of tests that we can run, most likely, 
we'll just run tests by hand that seem relevant to the subsection we 
messed with until we get automated testing worked out.

I'm going to close with some of the ideas I have for upcoming 
development.

	Take care,
	Alok

Alok's Plans:

Things to add in next few months:

	karyoscope: add postscript output						karyoscope: change "pixel per 
value" to y-zoom, add zoom in, out buttcons	karyoscope: change "pixel 
per map" to x-zoom, add zoom in, out buttcons	karyoscope: add overlay  
of multiple graphs in karyoscope	scatterplot: add postscript 
output						registration: add check to see that global xml config can 
be parsed/written, warn user if there is problem.	dendrogram: make sure 
that "compare with..." works
	dendrogram: document node-flipping and compare with... 
functionality	url linking: add note about escaping chars in windows 
URLs (Davin Townley-Tilson)	RAM: switch data model to floats instead of 
doubles to save RAM.	RAM: remove all refs to (String []) 
RectData.elementAt(i), use getString() instead.	general: change to MIT 
Open Source License				general: add check in makeTars that checks 
version in build.xml and TreeViewApp.	website: make web page with links 
to projects that use java treeview (GMOD, TAIR)	website: add k-means 
example to examples page			website: read over documentation to ensure 
that it is consistent with current application	

Bugs to fix in next few months:

	dendrogram: resolve node-flipping inconsistency
	dendrogram: fix selection triggered by opening "Find..." when no genes 
selected
	dendrogram: find doesn't always let you pop up summary.
	karyoscope: fix bug in export - yeast chr 16
	knnview: rename to kmeansview. Eclipse makes it easy!
	javadoc: during html generation, there are many (well, 73) warnings 
which should be looked at.

Things to do later:

	plugin architecture. make all views plugins, even dendrogram.
	add plugin for the SGT (http://www.epic.noaa.gov/java/sgt/index.html)
	use the SGT to allow arbitrary plots on karyoscope
	plugin for fuzzy clustering display
	implement GEO cluster browser helper application
	redo "knn" (actually k-means) so it uses normal tvmodel, dendroview, 
add group-by feature to dendroview
	try out new version of Your Kit Java Memory Profiler on JTV to find 
RAM leaks.