The Apple JVMs for OSX are incompatible with the current state of DepAn.  

DepAn currently relies on Java 1.6 - it is no longer 1.5 compliant.  We
could live with hassles of @Override in Java 1.5 vs 1.6, but other, more
fundamental inconsistencies are creeping in:

- The graph serialization (XmlPersistentGraph) relies on the StAX library.
 This is a Java 1.6 package.  It's possible to replace the StAX package a
DOM XML serializer, but that's very slow.

- Apple does not support the underlying SWT/carbon library that Eclipse
uses in Java 1.6 - see Eclipse bug
https://bugs.eclipse.org/bugs/show_bug.cgi?id=216051.  There are rumours of
a cocoa port for Eclipse; also maybe an Eclipse ported carbon library
(http://dev.eclipse.org/newslists/news.eclipse.platform.swt/msg21616.html),
put there is no out-of-the-box solution.

As of Oct 29, 2007, there is a new release of the JUNG third-party
package.  Our current system uses the 3.0 release (RC?), which comes from
November 2006.

Add Eclipse branding plugin so the application starts pretty.

May need to include disclosures or licenses for all third-party software.

The Relation Editor allows user setting relation rendering properties. 
This is supported at the level of individual relations.

A few enhancements
- Change its tool label from Edge editor to Relation editor.
- Allow relations to be sorted by any column.
- Allow multiple selection of relations.
- Allow simultaneous modification to all relations, even when multiple ones
are selected.
- Allow control over relation label presentation.

For now, we can analyze a jar file, or a directory containing .class files,
to find dependencies. Once this is done, the dependency graph is fixed.

It would be useful to have a way to merge dependencies coming from another
jar file / directories. The easiest way, and probably the most powerful to
is to provide a way of merging two .depang files into a new one.

Using standard XML/Jason/... for depang files, would simplify the process.
Alternatively we can provide a way to export/import depang files to/from
XML/Jason...

This would also provide a way of loading files generated from other
programs, and to analyze projects containing multiple jars for instance.

Currently, the JOGL libraries are bundled with the DepanApp plugin. 
Although this is convenient, it makes it difficult to re-target to other
platforms that require a different JOGL build.

If the JOGL libraries were bundled as a separate Plugin, different release
targets could draw different flavors of the Plugin.  We'd still might have
multiple deployment images at each release, but we wouldn't have to edit
the DepanApp/build.xml file for each one.

We now have a basic editor for edge rendering, but still no way to set
default values for the user.  Edge rendering should be integrated with the
Eclipse Preference model.

Related to issue 11
(http://code.google.com/p/google-depan/issues/detail?id=11).  This extends
the basic capability added there with Preference settings.

Mouse actions, especially selecting nodes, are very slow in the OpenGL
Goobuntu version.  It can take 5-10 seconds for a node selection to become
apparent in the ViewEditor.

This leads to some very awkward UI interactions, including delayed moves of
nodes off the viewable editor space.

From the Selection Editor, if you try to open a new view with the layout
option Keep Positions, you get nothing.

Repro steps
- Open an existing view
- Select some nodes
- Open the Selection Editor Tool
- Pick some relation group
- *Leave* Apply layout as Keep positions
- Press the Create new view button

Should get a new view created.  It does not happen.

If you change to a different layout style, the view does get created.

The Java/Bytecode uses a flexible method of dependency discovery and .dpang
file construction.  A dependency listener is notified of all dependencies
that are discovered by inspection process.  The listener determines if the
incoming dependency is new, and whether it is interesting (using injected
filters).  The incoming dependency is added to the output dependencies only
if it passes all of the listener tests.

This capability should be extracted from the Java/Bytecode components and
moved into DepanApp (or DepanCore) for reuse by other plugins.  It would
certainly help in the creation of a Filesystem wizard, and it would unify
the system with internal dependency wizards.

Give the possibility to open in eclipse (or any other software) a selected
class, field or method. This require the user to specify a source directory
for each graph.

For eclipse this could be done with an eclipse plugin listening
instructions on a port, and DepAn sending instructions on this port.
Instructions could be like "open class
com.google.devtools.depan.graph.api.Graph".

These steps will reproduce the problem:

1. Open/import a new project to the workspace.
2. Create a new graph analysis.
3. Create a new view using this graph analysis.
4. Open Tools window (Open Windows.Views.Other, Select DepAn Views.Tools)
5. Click on Node Editor (Currently 4th button from left)
6. Try changing the color or size of a node - It fails!

Apparently the Node Editor Tool is not linked to the graph for these
properties. 

As of 25 July, 2008, there is a new release of the JUNG third-party
package.  Our current system uses the Alpha2 release, which is at least one
year old.

The hierarchical layouts have been broken since ~ the OpenGL release.

Basic hierarchical layout seems to put all children and grandchildren*
nodes on a single line.

Radial hierarchical layout seems to put all nodes at the same place.

Add a Selection Tool (in Selection Editor?) that selects nodes based on
their type.  Probably should provided a NodeSet features similar to
RelationSet.  It would also be nice to have this integrated with Path
Expressions

Currently, only the hierarchical layouts use the relations sets.  This
should be expanded to all layout types.

The idea is to layout the nodes based only on the relations included in the
relation set.  All other dependencies are ignored for the purposes of
determining node location on the canvas.  Once that is determined, only the
edges from the RelationPicker should be rendered.  Note that these may be
disjoint set: some interesting effects are possible with this.

For JUNG layouts, this probably means cloning the JungGraph with only the
layout edges supplied.  After the layout algorithm completes, the resulting
locations would be copied to the presentation JungGraph.  In that graph,
only the presentation edges (RelationPicker) are visible.

Anytime a new ViewModel is created (GraphEditor, SelectionTool, etc.), the
user should be able to define an autocollapse relation set to use before
the ViewModel is displayed.

Ideally, the workspace should also support a workspace defined autocollapse
relation to use for any new ViewModel.  This can be empty.  The different
ViewModel generator interface should allow the user to select an alternative.

The Graph cache (depan.model.ResourceCache) should monitor the resources
and reset its saved content when they change.

To reproduce:
1) Create a newfile.dpang from the Hello World sample
2) Open the newfile.dpang -> it get loaded into the ResourceCache.
3) close the GraphEditor (still in ResourceCache).
4) In the file system, delete newfile.dpang
5) Create another instance of newfile.dpang using a different sample
6) Open the newfile.dpang
   -> you get the cached version with the Hello World sample.
   == you should get the new graph from newfile.dpang

I suspect that ResourceCache should move into the App layer, and use
Eclipse resource changed listeners to implement this facility.

What steps will reproduce the problem?
1. Open a saved view
2. move nodes around with the mouse

The view editor is not marked as "dirty". Therefore it is not possible to
save the view with new nodes positions.

Currently, many menu items are stuck in second level "Other..." menus. 
This is due partially to the lack of a "DepAn Project" type (which would
allow Eclipse/RPC to automatically fill in useful choices) and partially
due to just poor menu layout.

Regardless ot the implmentation mechanisms, a good menu system should:
* place DepAn views and wizards at the  top level
* prefer DepAn views and wizards over other contributions 

The top pane of the Selection Editor shows the current set of selected
nodes.  This should be made into a separate View to that uses NodeTreeView
to display the current nodes.

This will save real estate in the Selection Editor.  It also allows the
user to separately view the current selections, perhaps in a larger window.

On modest size graphs, it is easy to use the region select to choose many
nodes (mouse click-drag selection).  If the number of selected nodes
exceeds some small number (16?, 32?), the current mouse manager reports too
many selections and no nodes are selected.

OpenGL mouse should support selected all nodes in the graph.

The current definition of a Relation
(com.google.devtools.depan.graph.api.Relation) only provides for the name
of forward and reverse traversal of the connection.

It should provide a name for the relation itself (versus the
relation-pickers use of reflection), names for the head and tail node, and
the existing names for the traversal directions.

This will be a pervasive change to all dependency models, the
relation-picker, and probably parts of other relation components
(RelationSets?)

The new Edit.Select All menu choice is nice.

We should also have a keyboard shortcut in the ViewModel editor for
select-all.  ctrl-A would be a natural.

In the sublayouts, allow a set of selected nodes to be layed-out in one or
more columns.  Something like:

  blix
  blax
  blox

for short lists, or

  blix      red       meat
  blox     yellow     fish
  blax      blue     potato

Currently, few of the menus know about DepAn contexts.  This forces the
user to search in menus in the Other... selections, etc.  This makes for an
unnecessarily frustrating user experience.

Proposal:

Add a DepAn Project type, with a DepAn Nature.  This will allow the Eclipse
RCP to automatically select the DepAn wizards (e.g. New Graph Wizard) as
top-level choices.

Add a DepAn Perspective.  This should begin with a Project Explorer and the
Tools view.  The Project Explorer should be configured to offer New DepAn
Project as a top-level choice.

On new user launches of DepAn, the configuration should start with the
DepAn Perspective (possibly with a Welcome Page overlay).  This should help
new users get on their way.

Currently [Oct 2007], nodes can be selected only manually or by their
relationship to other nodes.

Sometimes, you just want to select all method nodes.

There should be a simple editing command to select all nodes in a view.

The Relation Editor allows user setting relation rendering properties. 
This is supported at the level of individual relations.

We need a mechanism similar to NodePreferences to all user defined
rendering preferences based on Relation type.  These should probably be
grouped by contributing plugin.

Preferences should include:
  * line style (including width and style-dependent options)
  * line color
  * arrowhead style

These references should be integrated with the Relation editor such that
most relations explicitly use the preferences, but these can be over-ridden
on a case by case basis.  It may also be appropriate to have a separate
ViewModel Relation preferences, which also defaults to the user/workspace
preferences unless it is overriden.

As of Jan 26, 2008, there is a new release of the JODA_TIME third-party
package.  Our current system uses the 1.4 release, which comes from
November 2006.

Currently, there are no ways of defining how edges are rendered:
- color
- thickness
- labels
- ...

The current Filters for the New Graph Analysis wizard should be better.

Since they are used with String.startswith(), they should automatically
terminate their strings with the terminator for their domain ('.' for
packages, '/' for directories).

The Directory filter should be implicitly from the root of the class path.
 This works by default for .jar reads, but the From a directory case should
automatically elide the root of the directory path before testing for the
Directory Filter.

Even better, a new UI should allow users to construct lists for each Filter
choice.

Fix SWT Exceptions for "illegal thread access": post update actions to SWT 
render thread instead of 
just calling the render method.

We need a Welcome page that helps new users create their first project and
use the New Graph Analysis wizard.

I tried hacking out something using Eclipse's Universal Welcome page,
but it was unsuccessful.  We should try again, or try something else.

As of Feb 26, 2008, there is a new release of the XStream third-party
package.  Our current system uses the 1.2.2 release, which comes from
May 2007.

When the selection editor includes (starts from?) a collapsed node, only
the collapsed node makes it into the new ViewModel.

The user needs to control how the collapse node is handle in the new
ViewModel.  These choices seem like a good starting point:

"Visible Only": Include only the visible collapse node itself (current
behavior)

"Expand collapsed":  Include the collapse node and all of it's children in
the new ViewModel.  

"Preserve Collapsed": Include the collapse node and its children as a node
that starts collapsed in the new ViewModel.

The Filesystem plug does not have its own dependency building wizard.  It
should be possible to implement as a straightforward tree walker. 
Admittedly, the dependency graph is simple - it should (almost) always be a
tree of dependency.  But it is a useful addition, and it will contribute
nicely to merge .depang files (Issue 10)

Some layouts (esp. JUNG layouts) run iteratively until they stabilize the
locations of their nodes.  A few of them never reach a complete state; they
will continue iterating indefinitely.  In the both of these iterative
cases, we artificially limit the number of iterations to 1000.

See com.google.devtools.depan.eclipse.visualization.plugins.impl
  .LayoutPlugin.setLayout() for the code in question.

Not only does this impose an arbitrary limit, it interacts poorly with the
user.  Some layouts (e.g. FRLayout) run for a very long time on large
graphs (>5min).  With no feedback, it can appear that DepAn is hung.

This kind of iterative layout should be run as a background task (i.e. use
the Jobs API).  The progress monitor should indicate the limit of the
iterations, and the current iteration.  The user should be able to increase
or decrease the limit, and should be able to stop/cancel the layout task at
any time.  When the layout task is stopped for any reason (stable, limit
reached, user canceled), the computed locations are used to render the
graph's nodes.

In the best case, the View should update incrementally as the background
task proceeds.  Maybe not on every iterations, but it would be nice to
visualize the layout as it proceeds.

Several of the layout need user supplied parameters.  For example, the
tree-layouts should be able to choose top-down or left-right orientations.
 Currently we have partial support for RelationSets, but only for
hierarchical layouts.

Maybe start by copying in the draft from over the summer.

Given two .dpang graphs, describe their similarities.

This will support historical comparisons of an evolving code base.  Given a
use like compare(old, new), we want to know:
- Nodes in common
- Nodes only in old
- Nodes only in new

?? What about relations?  Especially added relations?

As a first pass, the graphs may be compared using a hierarchy based on a
relation set (Containers?).  In such a comparison reposrt, we want to see
the changes at each level of the tree.

What steps will reproduce the problem?
1. create a new view
2. save it, and close it
3. open it

When loading the layout, a null layout is passed to the view.

The view is then supposed to used the saved positions for the nodes, but it
doesn't, and try to use null as a layout, throwing a NullPointerException.

For historical reasons, DepAn originally loaded only a single jar.

But there is no reason not to load Bytecode information from a list of
sources.  This might not follow exactly the semantics of classpath (i.e.
should type definition in the early part of the list dominate over latter
definitions of the same class?).

The UI that currently allows selecting jars or a directory should create a
list of Bytecode input sources.  Buttons should provide Add Directory..,
Add Jar.. browsing services and a Remove button. (See 
<Java Build Path>.Libraries tab for a related example.

On tools panel, flow tool icons into multiple rows when panel is narrow (i.e. 
on laptop).

Currently [Oct-2007], there is no way to get a hard copy or presentation
copy of any rendering.

Should be straightforward, but may need to hook into JUNG/Swing rendering.

Add a Selection Tool (in Selection Editor?) that selects nodes based on
their degree.  Probably with separate controls for in-degree and
out-degree.  Common values will be zero or unlimited.

This would be invaluable for identifying uncalled methods.

It would also be nice to have this integrated with Path Expressions

The collapse operation tool should add a capability to set wheterh
selecting a collapse node should also select its children nodes.  In normal
cases, this should be set.

This value should be at least a ViewEditor property that controls all other
selection operations.  One obvious place is the list of currently selected
nodes in the Selection editor tool.

What steps will reproduce the problem?
1. Create a view with only one node

The node is not visible. should be in the center.

What steps will reproduce the problem?
1. Open a view
2. Close this view
3. Create a new one and open it

The last view rendering is slow. Probably some opengl thread is still
running for the previously closed view.

The minimal set of collection classes (com.google.devtools.depan.collect)
should be removed, with the new Google Collections package as a third-party
replacement.

http://code.google.com/p/google-collections/