Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.
I've been playing with TouchGraph (specifically the GraphLayout 1.2.1 based version) for a few days now. I've able to hack together a basic utilization of TouchGraph fairly quickly. I whipped together a little prototype that traverses our persistent object graph and displays it in GraphLayout. I've been able to add a small icon (based on the patched code from Brendan), modify the little expand node box (to be a white circle with the number instead of a little red box), utilze different colors, modify the menus to launch related actions and display additional information, and miscellaneous other things. I think the app behaves pretty well and am seriously considering it for production usage in an application I work on. It took a bit of tweaking but I think I've figured out the gist of it.
Let me say that this is a very nifty capability to have and am just happy that I can find something that is open source that i can modify and extend on my own. However, the code feels really "hacky", is not easily extensible, and can be difficult to follow. For example, I wish that Node and Edge classes were interfaces so i could easily implement my own variations (and not have to much with the Node class itself). Also, there's also a lot of various instance variables and methods that are public or protected with no apparent reasoning. I'm not trying to put the project down (as I'm actually very thankful for all of the hard work that went in to it that I can now build on top of), I'm just contemplating the fact the project seems to be rather dead (other than a few posts in the forums), but there seems to be a need to improve and maintain this project as evidenced by the various forum posts. It's not actively being developed and is currently left hanging where it was about 2 years ago. I don't see any evidence that any of the code is accessible via CVS. It's probably about time for a newer version.
Would anyone be into "rebirthing" TouchGraph into a different project? I'm not trying to "compete" but if the project is dead and enough people have the gumption to improve it, why not? Anyone have any thoughts? Anyone know the author? What the current status of the project is? x_ander, are you around?
> However, the code feels really "hacky", is not easily
> extensible, and can be difficult to follow. For
> example, I wish that Node and Edge classes were
> interfaces so i could easily implement my own
> variations (and not have to much with the Node
> class itself).
It's funny you should say that, actually. The application we are using GraphLayout in has overridden both the Node and Edge methods entirely. They don't need to be interfaces for this. :-)
Part of the problem with making them interfaces would be that the location of the node is stored in the node itself. If they were interfaces, you would need setter and getter methods defined in that interface, which in turn would slow down the movement of the graph, which is already quite CPU intensive.
> Would anyone be into "rebirthing" TouchGraph into a
> different project? I'm not trying to "compete" but if
> the project is dead and enough people have the
> gumption to improve it, why not? Anyone have any
SourceForge already has another Java dynamic graph library online, called Prefuse. It might be worth checking that out, as design-wise it is much more sensible than TouchGraph's, renders a bit faster (possibly just due to drawing less on the nodes, though... Prefuse's default look is very plain), and is still in active development AFAIK.
> It's funny you should say that, actually. The application
> we are using GraphLayout in has overridden both the
> Node and Edge methods entirely. They don't need to be
> interfaces for this. :-)
Yeah. I initially extended Node and Edge with my own classes. I know it's possible, but I encountered strange behavior when trying to tgPanel.addNode(myNode) as opposed to tgPanel.addNode(). I later figured out that this was due to the fact that these methods do different things (which is pretty unintuitive from the perspective of the interface). Another strange thing that I encountered was that when I added my own nodes in which I defined my own ID for each node, even when I made sure not to add one that had the same ID again, I would get a TGException stating that there was a node with that ID already existing. This would happen repeatedly even when just traversing the graph. I didn't dig too hard to figure out why this was happening, but it seemed pretty obscure.
> Part of the problem with making them interfaces
> would be that the location of the node is stored in
> the node itself. If they were interfaces, you would
> need setter and getter methods defined in that
> interface, which in turn would slow down the
> movement of the graph, which is already quite CPU
I don't believe this is a significant an issue for modern self-optimizing JVMs. But perhaps this was done because TouchGraph is made to support jdk 1.1 and it makes more of a difference there?
> SourceForge already has another Java dynamic
> graph library online, called Prefuse. It might be
> worth checking that out, as design-wise it is much
> more sensible than TouchGraph's, renders a bit
> faster (possibly just due to drawing less on the
> nodes, though... Prefuse's default look is very
> plain), and is still in active development AFAIK.
Cool. Thanks for the tip. :-) I just checked it out and it looks very promising. The code is a lot cleaner and more OO too. ;-)
Jung is another Java graph library that seems to be under active development. From memory, one of their example apps was a Touchgraph-ish spring layout with selectable neighbourhood.
to me (and I've mentioned this recently in other forums), the key to TG is to implement importing in GXL format, which can dynamically add data to nodes as it's importanting the database. Then you can save, etc., much nicer. I'm going to make it a project of mine over the next few months.
That is, it can import an XML-like GXL file which has two sections - a header gxl describing the format of nodes and edges (what attributes each has, and their type, like int, or string, etc.), and following that by the edge + node list. Since it's going standard, this seems to make the most sense, that way TG wouldn't have to be rewritten for every database. Just write something that spits out graphs in GXL, and TG could do it - a little dynamic window that has the attributes + lets you edit them... and pop. instance database editors....
And I'd be willing to help on the TG revival. :-) Prefuse doesn't have all the functionality I'd like to see...
Interesting... yet another graph format. DOT format is already the most widespread in-use graph format, but I'd definitely love it if tools like Graphviz all supported an XML-based format, it would make my life much easier. :-)