Tags:
create new tag
view all tags

Scheduling a termination point for TJ

Since the focus of my PhD is not TJ, but applications similar to SJ, I propose a simple set of requirements for TJ:

  • TJ should be standalone and run in one packaged JAR, packed together with current dependencies (i.e. JOGL in it's current version will be the only graphics wrapper supported, and will be required if the source is unpacked and run)
  • TJ will be non-dependent on new changes to Accordion Drawing, and AD applications such as SJ and LiveRAC

I have had particular problems concurrently implementing a few applications with shared code, but by separating out concerns with TJ, the intent of closing TJ to future development should make new research less of a software engineering nightmare. Since most of the code is "research", it tends to change frequently to fit new research requirements or goals, and many times seemingly innocuous assumptions turn into hassles to debug at application level, as well as the base accordion drawing system level. To escape the cycles of simple updates for TJ requiring months of investigation and bug fixing for all possible conflicts with other applications, we will not add any more features, however nice. The intent is not to let TJ die completely, so we will continue to (passively) fix bugs or clean the code to make it easier to update, but all this non-research development will be in a separate source code branch.

Hillis changes

These changes were originally proposed Oct 2004, following the infovis conference in Austin. They have been put aside from being added to the main branch for several papers, graphics back-end rewrites, and interruptions. By separating from TJ, I hope these changes will be the last major additions to the TJ application.

  • approximately 4 major changes:
    • support for 8 groups (mostly UI extension, also clean up the GUI and eliminate non-functional widgets)
    • labeling for interior nodes to right of tree, where leaves are currently drawn, priority to deepest (topological) drawable label
    • control over individual label sizes, colors?
    • editable labels (node string name) for nodes, save changes back to tree file
  • integration of changes should be orthogonal to recent updates to TJ and accordion drawing in general. Most changes are isolated to the application level of TJ, with label drawing locations controlled by the tree drawing package layer (middle tier, AccordionTreeDrawer).

Timeline: approx 2 weeks

testing

  • some bugs have been added to the sourceforge bug tracking system, and testing will probably add more
  • jogl integration (and JSR updates) added a few problems that appear mostly in current versions of SJ, but may require investigating with more rigorous TJ testing
  • concerns about static wrappers hiding the dynamic structures used by SJ and LiveRAC need to be rechecked after SJ is stable. Updates to make SJ stable should be ready next week.
  • A final tag for the last version of accordion drawing that supports TJ and SJ would be nice, should be in the main cvs branch, and will be a good point to indicate a permanent branch for TJ.
  • fixes for easy bugs, migrating harder bugs to realm of known issues?
  • if any bugs appear to be AD related (including after TJ has been closed), they will be fixed in SJ or future applications but perhaps not TJ

Timeline: approx 1 week for minor fixes and testing on multiple systems

Topic revision: r1 - 2006-11-15 - JamesSlack
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback