Next steps for DepAn

[Lee Carver]

DepAn Users -

If you've been keeping track of the latest revisions (ha ha), you might have
noticed that DepAn's persistence for user settings is much improved. If you
start analysis with a Java file, it remembers that the dependencies are Java
centric. If you move nodes around in the diagram view, DepAn should remember
where they finished. And size to window is the normal process of new dependency
layouts.

After all this work on persistence and user state, it seems like time to pick a
new area of focus. Among the alternatives, these all seem like good ideas to me:

A) Improve collapse view support to handle selection better.

B) Improve layouts to support a richer set of options, and provide an Extension
Point that can be used to add new layouts in new plugins.

C) Expand the initial statistic page to support lots of analysis forms. This
expansion should provide an Extension Point that can be used from new plugins.

D) Build out the speculative refactoring support, so DepAn really supports
refactoring and not just analysis/visualization.

Based on my current analysis needs, I'll probably work on (A) to start with.
(D) is close to my heart, but it probably needs the most design work.

Please let me know if you have any immediate needs for these, or other, features
in DepAn. Engineering resources are limited, so I want to make sure the efforts
are focused on the most useful features.

Thanks
Lee

[Yohann]

Hi Lee,

I think A is great to do too.
I would love to see container relationships as.... containers. as
boxes (or big node) containing other nodes, instead of representing
them as connected nodes.

I don't know if its what you had in mind, but I am sure that would
help visualizing things too.

Cheers,

> --
> You received this message because you are subscribed to the Google Groups
> "depan" group.
> To post to this group, send email to de...@googlegroups.com.
> To unsubscribe from this group, send email to
> depan+un...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/depan?hl=en.
>
>

--
YC

http://five.sentenc.es/

[Lee Carver]

Ok. I kinda need better collapse support anyway for the types of dependency
analysis that I'm currently doing. At least one user (me) will get some advantage.

The notion of rendering container relationships as containment is a good idea,
and it probably fit into the current rendering system without too much trouble.
It does kind of depend on layout enhancement (B), since you'd want to select a
subset of nodes to layout and a specific subset of relationship to use for
layout (e.g. uses vs. containment). Once that works well, then we just scale
the contained nodes to fit within a box drawn by the container, and voil� ..
containment rendering. One trick would be limiting the contained elements to
their surrounding box (or resizing it as needed).

This also plays into a more sophisticated notion of relationships set.
Increasingly, the ViewEditor maintains some implicit relationship sets that are
shared across the different tools and propagate to derived dependency views.
The container ViewPreferences.treeRelationshipSet approximately defines the
current notion of "containment". This could be cleaned up without to much work.

More interesting are other recurring roles for relationship sets. In the simple
example above, there are both "containment" and "uses" relationship sets. For
some diagrams, it can also be useful to define a "layering" relationship set.
One approach, borrowed from Architexa, is to render containment as nested
diagram, layering as top-to-bottom ordering, and use as left-to-right ordering.
It's an intriguing idea, especially is you can mix and match the relationship
sets with different rendering notions. How might many different rendering
schemes and many different relationship roles be usefully employed?