- Moderator: cds
- Protocol: cds
- Author: cds
- Start: 12:30
- End: 14:20
Objectives and Introduction
The objective of this design meeting is to validate the basic design of KLay Layered.
The basic design and the class design is described on this Confluence page. You should read it to understand how KLay Layered is structured. During the meeting, we will basically be walking through all classes mentioned in the bottom-most diagram on that page. I would also like to have all intermediate processors as well as the different implementations for phases 1, 2, and 4 reviewed. That should not take long, since those are all just straightforward implementations of the interfaces and abstract classes we will have looked at before. The implementations for phases 3 and 5 are a bit more complex and should probably be reviewed during a second design review, along with the leftovers of this one.
We go through every one of the grouped parts in the architecture diagram, understanding how the different parts work together and finding design problems.
pack(...)method should be changed to
combine(...): its work is delegated to
AbstractGraphPlacer.combine(...), both methods should therefore have the same name and
combine(...)was found to be more intuitive than
getIntermediateProcessorList(final int slotIndex)is responsible for returning the list of intermediate processors in slot
slotIndex. This list is expected to be in a valid order, that is, in an order that satisfies the dependencies among the layout processors. However, how this order is arrived at was not clear from the code. In fact, the code relied on a feature particular to the
IntermediateProcessingStrategy: an iterator over an
EnumSetreturns its members in the natural order in which they occur in the enumeration, which in this case is designed to satisfy the dependencies. The correct order was thus implicitly guaranteed, without anyone understanding that behaviour. In fact, the
IntermediateProcessingStrategyofficially only returned a
Set, not an
EnumSet, making this situation all the more complex and even dangerous ("wherever there's danger he'll be there, DANGER MOUSE!"). This was now solved by having
IntermediateProcessingStrategyexplicitly return an
EnumSetinstance, and by documenting this stuff in
This were all the changes required. Afterwards, chsch came up with a use case he'd like to be supported. We talked about whether the design would be flexible enough to handle that one.
The Use Case of chsch
- Compute a layout for a graph.
- Replace multiple edges between any two given nodes by a single edge. This is done to reduce the level of detail when zooming out.
- Compute only the layout of the new set of edges.
This is a very restricted use case in which we can guarantee certain properties for the edges in the second layout. The most prominent is that we know that the number of edges can only shrink compared to the first graph. The following could be an idea for implementing this case:
- Use the interactive cycle breaker.
- Use the interactive layerer.
- Use the interactive crossing minimizer.
- Use a fixed node placement.
- Use the orthogonal edge router to compute bend points while not modifying the x coordinates of nodes.
There are a few problematic points:
- The interactive crossing minimizer cannot infer the placement of long edge dummies of the edges since the edges weren't there in the first layout and thus have no coordinates assigned to them. This must be solved somehow.
- The edge router might find that the spacing between layers is not enough to accommodate the edge routing.
All in all, however, this case might just be solvable. We'll keep that in mind for the future.