separating graph layout and the dynamic....

Mark Smith
  • Mark Smith
    Mark Smith

    How hard is it to separate the graph layout and the dynamic movement of nodes + edges on the client side?  Ideally I'd like to move graph layout to the server side so any one of my clients will get the exact same graph layout, but then have each client do the dynamic movement on it's own (so the server side creates some new GraphElt object or something and passes it to the client, client examines the differences in the positions of the nodes and does it's cool dynamic movement).  Currently the three methods called in TGMotion.relax() look too intertwined for me to interpret.  Is there anything I can do to help?

    • A quick comment: If you are talking about TGMotion, rather then TGLayout, then you are looking at an outdated version of the code.  You should take a look at which was released on September 30.  (I disabled hyperbolic edge bending in this version, to see it, run GraphLayout.jar from TGGL_105)

      Doing the layout on the Server side is an interesting idea.  I definitely like the goal of allowing multiple users to see the same picture of the graph in realtime.  However, it would also be nice to users the freedom not to have the same layout as everyone else.  This way, users can independently browse about a large graph, and make changes in remote parts without interfering with each other.

      So I wonder what the best implementation that allows for both synchronous and asynchronous browsing would be.   I could imagine a situation where the server would only store position information, but it might make sense to have a server side layout module as well.


      As far as the model-view separation of nodes (and edges) is concerned, it seemed to me that a the current Node class contains three types of information:
      Drawing:   Color, font
      Layout:    dx, dy
      Graph:     Node.edges

      The problem with splitting the nodes up, is that there are also variables like Node.x and Node.y,  that are used for both drawing and layout.

      Something that I was considering, is creating a NodeLayout class, which would have x, y, dx, and dy as its variables,  and letting each Node have an instance of this class.  This way, functionality could be added to TGLayout and NodeLayout without changing the code for the Node class.  What I wonder though, is whether the readability achieved by creating new classes will make things unnecessarily complex.  So for now, I am guessing that I will keep Node as a single class.


      I don't know if any of the above would make it more or less difficult to do the Layout on the server side.  I am guessing that if you can get the messaging right, then the rest would be easy.

      Otherwise, if you would like to contribute to the project, then I would really appreciate it if you could keep your code public as long as it remains general (as opposed to application specific).  Let me know if you have more ideas about how to implement the model-view split, or anything else. 

      Thanks a lot,


    • Another separation thought:

      I find the TouchGraph functionality very interesting.  I have also been looking at JGraph, which does have separate data and view models.

      I have an application that needs to have a consistent data model for multiple users, but I want to allow them to manipulate their views independently.  I like the TG notions and think they are applicable, in addition to some other user controls that would allow, for instance gross pruning of the view.

      So the question is do you think the TG view notions can be used to extend the JGraph view capabilities?

      Thanks in advance
      Steve P.