Diagram sizing

[devaigergely81]

General observations about our generated diagrams:

• too much space between boxes
• too big boxes (=> too small text after zooming out to fit the diagram on the screen)

I attach a few pictures to illustrate the problem.

Zooming out to fit the diagram on the screen, text unreadable:

Zooming in to read text, diagram does not fit:

Then I deleted all elements from the diagram and dragged&dropped them back manually and I asked Papyrus to arrange the diagram: The layout is ugly, but it fits on the screen and the texts are readable at the same time:

[devaigergely81]

This is a generalization of issue #83, therefore I'll close that.

[dobreffandras]

The extreme scaling of diagram elements is a cause of the length of the attributes in the classes. In the attached pictures one of the classes have an attribute that is very long. The current algorithm takes the maximum value of width and height from all classes. With this value the algotithm resizes the classes in both directions. The space between them is resized as well.

Actually the relation of size between classes and spaces is pretty good in my opinion. The problem is with the texts.

Solution: As long as the arranging algorithm is based on a grid and cannot cope with different sized entities the following solutions can be implemented:

• Ignore the length of the attributes and leave the classes with their default (100x100) size.
• Take the length of the attributes into consideration but define a maximum size for classes.
• Take the length of the attributes into consideration but with a smoother multiplier.

In all three cases we have to give up the need that the attributes are visualized with full text.

[devaigergely81]

One more possibility: The attribute length only affects the width of the boxes, and the height is based on the number of attributes. So all boxes would have the same width and all boxes would have the same height, but the width and height could be different.

In addition to this, I agree with the "define a maximum size" suggestion above.

On the other hand, I think that the space around boxes is still too much.

[GregoBalu]

Yes indeed the spacing seems to be 1 grid bigger than it should be. The strange thing is that this issue was fixed back in the days, but I will look into that for sure.

The arrange can handle different width and height for the boxes-rectangles, and we would need the following anyway: calculate the width and height for each class using papyrus and give those pixel values to the arranger algorithm.

Also we can try alternating the corridorratio() statement's parameter, and maybe define a default value less than 1.0. This is the value that adjusts the space between classes. Edit: I really think that this will solve the problem, papyrus also does not use a class-box wide gap between each element.

These option setting statements (corridor ratio and overlap arrange mode) are not yet accessible from the UI nor the layout definition.

[dobreffandras]

Using the features (differnet size, corridorratio) of the layout algorithm we have improved the arranging mechanism. The algorithm takes the real sizes of boxes into consideration so different sized element can be arranged as well. In addition there is a limit (200px) for width and height as well. These improvements prevent the overscaling of the diagram.

With the "corridorratio" the gap between elements can be nicely reduced. Currently this option can be adjusted through statements. It should be a use-case decision that either we integrate this feature into the layout language so this ratio can be set for diagrams identically, or we take this option as part of the preferences and place it on some GUI.

The following picture shows a similar model but with the new adjustements in the algorithm. (Corridorratio is 0.5 in this example)

[devaigergely81]

Solved after merging back #209.