Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tala improvement suggestion: grow containers #26

Open
judepayne opened this issue Jan 27, 2023 · 5 comments
Open

Tala improvement suggestion: grow containers #26

judepayne opened this issue Jan 27, 2023 · 5 comments

Comments

@judepayne
Copy link

Hi,
I previously worked on a pet project similar to d2 - but not nearly as good! :) - based on graphviz, for producing technology architecture pictures. I found that a lot of diagrams would look much closer to one that a person would draw by introducing a 'grow-clusters?' parameter.

It would take a picture from this:

image

to this:

image

Graphviz doesn't have that setting and didn't have the man-power to introduce it so I had to hack the svg and run an optimisation over it. It was ugly!

Can work wonders though for some diagrams. Any thoughts for tala?

This setting might not work as tala; In graphviz (dot) you can force clusters into a row/ rank in the dot algorithm for introducing a bunch of between cluster invisible edges and from my experiments with tala, it works quite differently to dot.

@alixander alixander transferred this issue from terrastruct/d2 Feb 1, 2023
@alixander
Copy link
Contributor

i've long thought about how to dynamically change sizes for better layouts and haven't found a good solution. i think this is a special case where in a hierarchy of multiple levels within containers AND all the nodes in a level are in that container, you can expand the containers. which... hm, maybe we should just have all container widths match in such an instance. @ejulio-ts any thoughts?

@judepayne
Copy link
Author

Thanks at @alixander
The solution I came up with (just as a suggestion/ fyi) was to allow containers to (only) grow. Given a container at a level (i.e. inside a nest of containers), any other objects; shapes or (other) containers at the same level were treated as obstacles - i.e. the growing container was not allowed to grow into them.
Since there can be multiple containers at the same level that could each be allowed to grow, you had to use a linear optimisation rather than setting sizes directly. In my case that was just simulated annealing: grow a random container side a random few pixels, check that it hadn't grown into the obstacles and if not accept the move. Then pick another random container at the same level ...
At the whole graph level, the container level can be thought of as arranged in a tree. The algorithm above worked up the tree from the leaves to the root. The root might be a container or if multiple containers at the top level, you'd think of 'canvas' as being the root node of the container tree.
In sort of works and for a particular class of diagram, produces a picture that is closer to that which a person would draw. But I always wished it was not a post-processing step and good be merged into the (linear) optimisation that does the layout - i.e. all done in one pass.

@ejulio-ts
Copy link
Contributor

I see that, by doing so, you remove some clutter from the diagram as the container boundaries are well arranged and there's no space between them.
It also eases the problem of routing as now you must go through containers, there's no way around them.

If I understood it, if there were another container on the same as settlement for example, that level would be split in two different regions. Is that right?
If so, what about containers inside containers? Or, maybe this is just for the case of single nesting level.

@judepayne
Copy link
Author

re. visual clutter & routing: agreed

re. settlement and container on the same level. Yes exactly, here's an example with two containers on the same level after post-processing to grow the containers:

image

re. multiple levels. No, it works for deeply nested containers. Here's the same example, but this time I'm creating new containers 'Random 1' and 'Random 2' inside the pre-existing 'Reporting' container to hold the nodes there:

image

I've stopped the containers growing all the way to the edge by a couple of pixels to make the nesting easier to see.

In the above example, the tree that describes the containers is:

image

The 'container grow' algorithm works down from 'Current State' the root, at each level growing the child containers as much as possible, and then moving down to each of their children and repeating.

@judepayne
Copy link
Author

Was thinking. I think have this feature/ sub-algorithm within Tala is quite dependent on controlling the amount of empty space in the diagram to reasonable levels (the other Tala issue I previously raised). If there's too much space, growing the containers could result in largely empty containers and that would look weird.
I was experimenting with Tala 0.2.14 yesterday and there's still a lot of empty space for some graphs. I think I will re-open that issue and post an example or two.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: No status
Development

No branches or pull requests

3 participants