[Jtreeview-devel] The Future of Java Treeview development
Brought to you by:
alokito
From: Alok S. <al...@ca...> - 2004-12-15 11:00:59
|
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. |