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

Depth Map relies on graphs having child areas #77

Open
Eddykasp opened this issue May 3, 2022 · 0 comments
Open

Depth Map relies on graphs having child areas #77

Eddykasp opened this issue May 3, 2022 · 0 comments
Labels
bug Something isn't working

Comments

@Eddykasp
Copy link
Contributor

Eddykasp commented May 3, 2022

Currently the depth map assumes that graphs always have child areas. This results in features using the depth map such as smart zoom and the planned proxy-view not working for graphs which do not use child areas. In those cases calling getContainingRegion always returns undefined.

The big issue here is conflating rendering details with the underlying graph structure. kChildAreas are rendering elements, however they also fulfill some structural role, which is probably why they were misused here in the first place. Fundamentally the question is: should child areas be only a rendering element or should they be some structural element. In that case would it be reasonable to demand that any hierarchical graph has to use child areas?

If the responsibility is shifted into the diagram syntheses, the rendering doesn't need to specially handle the special case when no child areas are explicitly defined. On the synthesis side the solution would be to assign the child area (if none is explicitly defined) to the "main" rendering of the node. This should correspond to the way it currently works anyway, while improving support for rendering features that utilise the structural information provided by child areas.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant