Degree of automation for hierarchical edges #136
-
Hello all! This is my first question around, so I wanna start by thanking you all for the amazing effort! :) I have a question regarding the automatic drawings of edges. As disclaimer, I've not read the papers that discuss the ideas behind ELK and KlighD in detail, so I beg your pardon if the answer lies there (I accept references to the papers too :) ). My terminology is directly taken from the ELK data structure section. I am trying to visualize a KlighD model in which there are hierarchical edges, starting from a KGT file. Something like:
But the generated diagram does not contain the edge between I understand that from a holistic perspective it might be disadvantageous to support his type of model directly, as different users might have different expectations of what kind of diagram should pop out. But I wonder if there are some nice and still hidden options to be able to render this without manual elimination of long hierarchical edges? By manual I do imply a polynomial algorithm in time and space to do the ports and extra link creations in order to reduce long hierarchical edges to short hierarchical edges. |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 2 replies
-
Sorry for the late answer here, I forgot to activate the notifications for new discussions here and did not see this until now. The KLighD VS Code Extension is indeed only to be used as a library to be used by other extensions. But recently we published a first release of our KIELER VS Code extension, supporting the .kgt language among others. You can find that extension to view a diagram of your .kgt in VS Code in the marketplace. If we did not answer this yet when we met on FDL and for further reference, the answer to your question: To use the hierarchic edges, the ELK layout needs to be made conscious about the fact hierarchic layout should be used, in .kgt by providing this property at the top level graph: However, for this use case this will result in an incorrect rendering order for the hierarchic edge (will be drawn under the target node, I will create an issue for that). In general, hierarchic edges can get problematic in different ways, so avoiding that in general may give better results. Here your presented .kgt with the drawn edge, while avoiding a real hierarchic edge by routing the edge through invisible ports at the hierarchy levels, which you called the "manual" approach:
|
Beta Was this translation helpful? Give feedback.
Sorry for the late answer here, I forgot to activate the notifications for new discussions here and did not see this until now.
The KLighD VS Code Extension is indeed only to be used as a library to be used by other extensions. But recently we published a first release of our KIELER VS Code extension, supporting the .kgt language among others. You can find that extension to view a diagram of your .kgt in VS Code in the marketplace.
If we did not answer this yet when we met on FDL and for further reference, the answer to your question: To use the hierarchic edges, the ELK layout needs to be made conscious about the fact hierarchic layout should be used, in .kgt by providing this property a…