From: Martin B. S. <ma...@be...> - 2008-04-26 21:48:32
|
Hi folks, I'm trying to create a Spring-based layout, but I'm running across a few little "quirks" in my implementation :o) - How do I know when a node is being dragged and when it is released? I implement setLocation() correctly, but when someone drags a node, my layout moves it before they stop the drag, making the mouse lose sync with the node. Right now, I've decided to lock any node being modified outside the layout, but I'd like to let them ago again once they finish being dragged. - Is there any easier to find out a new node/edge was added or an old node/edge was removed? It seems like the current method is just to 'be surprised' when I find new vertexes and edges. Unfortunately, my layout adds some extra repulsion forces to anything not attached by a spring. This quickly becomes a headache to re-compute all those every time I notice a vertex, and my other option is to add even more state to the layout. I'd love an interface or some way to get notified of exactly what changes were made. Thanks, Martin Smith, Systems Developer ma...@be... Bureau of Economic and Business Research University of Florida (352) 392-0171 Ext. 221 > -----Original Message----- > From: Joshua O'Madadhain [mailto:jos...@gm...] > Sent: Thursday, April 24, 2008 6:58 PM > To: Martin B. Smith > Cc: jun...@li... > Subject: Re: [Jung-support] Pretty Animation of SpringLayout > while adding nodes > > On Thu, Apr 24, 2008 at 3:26 PM, Martin B. Smith > <ma...@be...> wrote: > > Hello all, > > > > I'm interested in a layout from a visualization I saw last > year after > > learning about the "Processing" tool at OSCON. Processing > is like a > > scripting engine in Java, with some nice libraries for > animation and > > applets. I'm specifically interested in the layout of some > nodes using > > a particle physics engine that is part of Processing called Traer. > > > > The tool I saw visualizes HTML structure on a webpage. > > > > Here's an example: > > > > > http://www.aharef.info/static/htmlgraph/?url=http%3A%2F%2Fjung.sourcef > > orge.n > > et > > > > I'm both impressed by the node-addition and the stability of the > > result as well as the node placement. > > A couple of notes to start: > * We've never focused on layouts that look good as they > animate, or on dynamic layouts in general. Our layout > algorithms are generally concerned with figuring out how to > place the vertices based on local constraints (force-directed > layouts, e.g. FRLayout) or global constraints (distance-based > layouts, e.g. KKLayout). Any graceful handling that they do > of a changing graph is a completely gratuitous bonus. :) > * Doing good layouts is generally easier with trees. (See > the various tree-related viz demos for JUNG2 that Tom's put > on the website.) > > > (1) My Spring layouts in Jung don't ever look that smooth! > They don't > > ever settle that quickly. > > The SpringLayout algorithm is a hack that Danyel threw > together a long time ago based on a demo on the Java site. > It works, sort of, but we've said for years that we needed a > better implementation of the basic idea; we've just never > given it high priority. We would welcome a better > implementation if you (or anyone else) would like to > contribute one. (We were offered a few from GUESS a while > back, but it's GPL-licensed and we wanted to leave JUNG as > BSD licensed. :( ) > > > (2) The node-addition never animates that nicely. It looks > like the > > nodes are added in a location "near" the ancestor > > Looks to me like they're added basically on top of the parent, yeah. > > A few months ago, someone contributed a mechanism for > generating initial placements for vertices based on existing > placements of connected vertices. I haven't tested it, but > the basic concept seems sound and simple enough, so we hope > to incorporate it in an upcoming release. > > > AND it looks like the viewer > > zooms out as nodes are added. > > This is something you could do now, if you wanted. You can > do zooming programmatically, of course, and basically what > you could do is keep track of the vertices with max and min x > and y values, and adjust the view (and the layout bounds) as > vertices get close to it. > > > (3) The example also seems to place nodes at the same level at > > different distances from the ancestor node, which makes for a more > > compact (and acceptable, for my purposes) graph. > > Could be that SpringLayout or FRLayout would do that given > the right starting conditions. > > > (4) My layouts in JUNG always have the tell-tale > box-shaped boundary > > when I zoom out. I want to resize the layout's canvas of space to > > work with when I zoom out -- I think doing that > dynamically on an add > > might cause an effect like (2). > > See above. > > > Does anyone have any ideas about this? Have you seen this > layout before? > > I can't tell from looking at it what the layout algorithm is. > > > Should I pull out the Traer engine and plug it into a > renderer in Jung? > > If you have that option and JUNG isn't doing what you want, I > don't see why you shouldn't give it a shot. > If you do, let us know how it turns out (and if you have any > questions on the JUNG side as to how to approach this). > > One thing I did notice on the demo that you linked to in your > subsequent email: that algorithm appears to have the same sort of > O(n^2) performance (per iteration) that the JUNG layout > algorithms have--at least it gets awfully slow if you hold > that space bar down long enough for a bunch of vertices to be added. > > Joshua > -- > > jos...@gm......................www.ics.uci.edu/~jmadden > Joshua O'Madadhain: Information Scientist, Musician, > Philosopher-At-Tall It's that moment of dawning comprehension > that I live for. -- Bill Watterson My opinions are too > rational and insightful to be those of any organization. > |