Skip to end of metadata
Go to start of metadata

Meeting Details

  • Moderator: cds
  • Protocol: cds
  • Attendees:
    • cds
    • ckru
    • uru
  • Start: 10:25
  • End: 10:50

Agenda

Objective

The objective of the first KLay Force review is to review the custom graph model used by the algorithm. I have added a Confluence page for KLay Force that contains a class diagram of the graph model.

Review Comments

General Comments

  • ckru: Do we need a special graph model for the force layout algorithm?
    • uru: It's good design to encapsulate the graph structure to be able to modify it as needed.
    • Decision: We'll keep the current FGraph since it would be more work anyway to abolish it.
  • ckru: In the KGraph, each graph is a KNode. This is not the case in the FGraph.
    • cds: While KGraph needs to support hierarchy, the FGraph doesn't since the Force-Based layout algorithm doesn't support hierarchy.
    • uru: It might be interesting to add some form of hierarchy to be able to add optimizations such as multilevel layout.
    • Decision: If we redesign the graph anyway, add support for algorithm-internal hierarchy as required for multilevel layout. There are first hints at hierarchy in FNode.
    • uru: The question is whether to keep or abolish FGraph.
    • Decision: This will be decided by the person who restructures the graph structure.
  • ckru: Ports are not supported yet.
    • Decision: We won't support ports just now since it's too much work and since we don't have an immediate application.

FGraph

  • Decision: Remove getBendpoints()getEdges()getLabels(), and getParticles().
  • Decision: Check if nodes needs to be a LinkedList.
  • Decision: Check if the adjacency matrix can be removed. If not, make sure the matrix gets updated automatically instead of having to call calcAdjacency().

FEdge

  • Decision: The desired edge length is currently encoded in the priority property of an edge. Instead, the edge should have an explicit desiredEdgeLength field.
  • Decision: Check if getSourcePoint() and getTargetPoint() are really necessary.
  • Decision:getVectorChain() is not required for the algorithm, only for the application of the layout results to the KGraph.

FLabel

  • Decision: Eliminate refreshPosition().

FBendpoint

  • uru: It's not clear if we need a list of bend points.
    • cds: There are algorithms that use bend points to eliminate edge-node-crossings.
  • No labels