Design issues and future additions
This document contains a set of unresolved issues, directions, and a to-do lst for the Diva graph package, ranging
from very specific details of the packages. Any feedback on any
of these issues would be greatly appreciated.
Design Issues
diva.graph.layout
- How to deal with self-routing edges and layout algorithms that expect to be able to route edges? For example,
if a levelizing DAG layout algorithm expects to be able to route an edge between levels of the DAG, but the edge
happens to be Manhattan-routed, what should it do? Let the manhattan algorithm possibly do a crummy job of routing,
because it lacks more complete problem information, or try to route it itself in the manhattan style, or simply
reroute the edge in whatever way it sees fit, and let the application handle the rest... For the the moment I have
created a method reroute(GeneralPath hints) method, which allows a layout
algorithm to pass hints into the routing algorithm. However, I don't think this is the best solution because there
is no guarantee what the routing algorithm will do with the hints...
Future Additions
Graph nesting support *
The graph model currently supports nesting of graphs, as does the display, but it hasn't been fully tested.
Manhattan edge routing *
I have actually written code to do manhattan edge routing (L-shaped routing of edges), but I didn't have enough
time to clean it up for the release. Next time.
Better layout algorithms *
Layout algorithms are tricky, and I'm frankly embarrassed by the layout support in this release. I intend to
add a few different static and incremental layout algorithms for next time, but I suspect this will be an ongoing
area of improvement, and I don't expect it to ever reach the robustness of commercial systems.
Modular editing behavior
The editing behavior of the GraphPane is currently a mess, hacked in for the release. It's a good day's work
to pull this out and make it more comprehensible (and more easily customized to a particular application).
Component abstraction for CAD editors*
Since my area of interest is CAD and visual programming, one of the big applications of this package is CAD
editors. We have a first-cut at this in the current release, but it will probably undergo several revisions before
it stabilizes.
Random Thoughts
I have a bunch of random "thought bites" which give some indication of the graph package directions.
It is more high-level than the future additions page, which describes specific additions
to the package that we intend to make over the next couple months.
- Graph is the first example of a visualization protocol. What we learn
from graph can be applied to new protocols, written in "how-to" guidelines, published even.
- We should think about the graph editor design in terms of its role as a visualization "surface."
It might end up exactly the same... my guess is that it will be a small superset of what we might otherwise come
up with.
- Axes along which graph panes can be divided (apart from different renderers and routers):
- Graphs can be edited or not edited
- Edges connect to nodes or to "ports" (components)
- Hyperedges or not.
- It's important to make GraphPane (in possibly > one version) as small as possible. This means that most
of the work is done in reusable components, so that if the parameterization we provide by renderers, routers, client
listeners is not enough, then it's not that hard to find a starting point for writing your own. In fact, it should
be possible to write a high-performance version of GraphPane (to display large graphs, say) with minimal effort.