Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Vincent Richard
    @vrichard12
    @le-cds Sure! Sorry for the delay in my answer. I opened the ticket #469
    Christoph Daniel Schulze
    @le-cds
    @vrichard12 See my reply in that ticket. I believe you actually tested against the old code due to some build problems ;)
    @lredor Sorry for my consistently late replies... Regarding your loop question, if your graph is simple, you could set a layer constraint on the node which is supposed to be the leftmost node.
    @lredor And no, there is no way to mix layout directions in a single graph, sorry. The layered approach is based on the assumption that we're working with a single layout direction. :/
    omygoodness
    @omygoodness
    graph.png
    Hello, I am trying to build a graph and everything is working great but I have one small issue. I don't know how to position these two nodes marked on red at the same level.
    https://bit.ly/2E4st1W - here is my model with JSON
    Any help will be really appreciated :)
    Ulf Rüegg
    @uruuru
    If it's fine to have both of them at the very top, you could set this option to FIRST for the two nodes you mentioned: https://www.eclipse.org/elk/reference/options/org-eclipse-elk-layered-layering-layerconstraint.html
    Let me know if this helps.
    omygoodness
    @omygoodness
    FIRST might be a nice solution but my question is if there is a solution to the whole tree. I mean generic option to set on whole tree object because with FIRST I need to add some condition before the tree is generated and check each node with it and after that add to proper node this FIRST option
    Ulf Rüegg
    @uruuru
    I'm not sure I understand you completely. Do you want your graph's sinks to always be placed at the top? Or do you want to be able to specify for a set of nodes that they shall end up on the same level?
    Try LONGEST_PATH for this option (set on the parent node of your "tree"): https://www.eclipse.org/elk/reference/options/org-eclipse-elk-layered-layering-strategy.html
    omygoodness
    @omygoodness
    This case which I sent is only one of many cases I will have and my question is if there is a generic solution for such nodes (this node has no connections on top like first one) - to auto-detect them and set position correctly or should I check them in each case and do it manually?
    Ulf Rüegg
    @uruuru
    Longest path should do this automatically but may produce results that you are less satisfied with. The other option would be to traverse your graph - find the sources (I meant sources instead of sinks in my previous answer btw) - and add FIRST to them.
    There's no option to do this automatically
    omygoodness
    @omygoodness
    I will check both options. Thank you very much for help :)
    Ulf Rüegg
    @uruuru
    You're welcome
    omygoodness
    @omygoodness
    image.png
    Another quick question. FIRST is working great but now I have another challenge. I am using mergeEdges and still have 4 connections instead of one. I marked nodes to which node on top is connected. Is there any option that will resolve my issue?
    image.png
    graph2.png
    Sorry for uploading the image 3 times... These are options which I am using on root
         'elk.algorithm': 'layered',
          'elk.direction': 'DOWN',
          'elk.hierarchyHandling': 'INCLUDE_CHILDREN',
          'elk.layered.mergeEdges': true,
          'elk.layered.spacing.edgeNodeBetweenLayers': 40,
          'elk.layered.crossingMinimization.semiInteractive': true,
          'elk.layered.nodePlacement.bk.fixedAlignment': 'BALANCED'
    omygoodness
    @omygoodness
    I found a solution with `hypernode' set to true but what is hypernode exactly? Documentation is not describing it very well.
    Ulf Rüegg
    @uruuru
    Either way your result looks rather unfortunate to me and I'd have expected that the edges are merged. @le-cds do you see a reason why this is not the case? Bug?
    Regarding hypernode I've to refer you to @spoenemann or @le-cds as well.
    omygoodness
    @omygoodness
    image (1).png
    omygoodness
    @omygoodness
    Works only with hypermode set to true
    Christoph Daniel Schulze
    @le-cds
    @omygoodness Could you use the ELK debug output features and send me the compressed log folder? See this page for more info (bottommost two sections)
    omygoodness
    @omygoodness
    @le-cds I am using javascript version of ELK(https://www.npmjs.com/package/elkjs) Can I still export logs with this package?
    omygoodness
    @omygoodness
    I see only this: https://jsoneditoronline.org/?id=b332b522c56b4179a4801d87b04a610b in logging section but I am not sure if it is helpful.
    JSON I attached displays tree about which we are talking about without setting hypernode option
    rk851
    @rk851

    Hello. I need a graph laid out in ther following way:
    First level:
    Exactly one graph node 'G'
    Arbitrary amount of subgraph nodes 'SGx' which are arranged tree-like below the graph node 'G'

    Second level:
    A sequence of 'T' nodes and forks ('F')/merges ('M') laid out from left to right.
    'T' nodes can only be connected to other 'T' nodes or forks/merges with no more than one edge.
    Forks have exactly 2 outgoing edges to other forks or 'T' nodes

    Third level:
    'D' nodes which are connected to the 'T' nodes.

    Every node except 'G' is connected to 'G' or 'SG' nodes with exactly one edge.
    You can find an example graph here:
    alt
    Is this achievable in some way with the algorithms built in in ELK?
    I thought about putting the nodes of each 'level' into their own child node (which is not connected to anything by edges) and let the first level be layouted by "ELK Mr. Tree" and the second level by "ELK Layered".
    But what would I use for the root node and the third level to stitch everything together with the needed edges? Is this kind of layout possible with the layout algorithms given by ELK? Or would I be better off implementing my own?

    Laurent Redor
    @lredor
    2020-02-26_11h58_28.png
    Hi,
    I have a diagram that corresponds to a list. In the example, there are 4 list items.

    The order is not kept during the layout (element3 is located in first). I see no reason for that.
    Question 1: Is there an explanation?
    Question 2: Is there a way to keep the order?
    Question 3: Is it a bug?

    The example can be test here:
    https://rtsys.informatik.uni-kiel.de/elklive/elkgraph.html?compressedContent=OYJwhgDgFgBA4gRgFABswE8D2BXALjAbRgGcBLALwFMAuGAZjoAYAaeugNhgF0kA7TACaUAyhUoA6AMaZexXOFK9cxWgCICAOQDyAEQCiAfQAyAQQBCeo8NYBZAJIa7NgKo2DwuwC09XVUiiklOAgklDoABJgvAIoisC0DgDCRs76BonhdkY6AEp6GkhgKMCYIKS4UAC2tKXA4pSSsRDEEpQoANbiaOhBlAJ8mEYYOLi08tiUA0Iw0kpgikEwAN5IAJDdI4RrqxCYZLikMrQATCwwp9tkVCcAnOysxzeMazyr-EKiVFIycgpKKjB1No0qYLFZbA4nK53F4fH5VgEgmAQmFItFYrx4jAkik0hksrl8mt3iIxOJKopSJVsNVAQAKOjHcQsAAs7GZAEp4W1OhAwAIBHE1ARcJgIABedksFCUABmuHFCGZzAARphcKLKorlWVgFAFUrGL41sQ+ZI4uISRpBDQYM91mAVW0YEYEGpZrh5rwgqpltsNngtqtg7t9odeLQEMcWawAKzbVZXW0sgAcD2QwdebxtQydKGI4ggaEklEqlCUwvC6XyABU9DlWAA1Aw1rQABVYDg8+mNqwAvsSbTA9DKy0oEH7gwH8AQE6HyuHI6xGQmk7cYzBY3RtlmSZ8JLNfl7lMLgYZQZZrDB7I4XG4PN5ewjAsFQhEojEhdiNMlUoZ8dkeQFMGe5khSvBUjSah0scKbKscUpcv6jrOkYxxqCOpblrgCC+iswYOlggazgRiZiLQKb3OcGYEfOBxHHacYJlm2ZCLmbQFkWYAlmOoyAgQVaJLW9ZNi27adho3ZwtsA79oO0yYbxxyToRmwkSGewLgxCCsCm8YEWu5w3Busb2qsu42vu3yyPIx4AkCujnuYl4Qre0IPtJwaIq+qIfhiWI4n+6SZIBRIgZZYGUtStKqDBcEsMcADsnLwg6eYunQGGjthxx4Qm05BgZ5EwJR6YJjsmn0RGjEwOwzEJiS7H5oWxZYRW-GCcJDYwM2rYdt+UlPrJskksO2VKHQKkFepFVhtprAIHQ+nBoZjwbolNEWR8ZKHrZignvxZ7GM54LXpCd4wo+qXecib5op+mIJD+uL-iFhLAaxpJfOBkExXF8HJYwSFTihKAuiyWVtbgdB5QR03lYZpXUeVdGLjVdUESxjWg5xrW8ZW1YaHW3W9eJA12D2qXDfJlBjVDLJTcMxFzpVaM6ecjAYytxVrbp26ZtsoFfLtfwHQ5IInVeN5QvesJPjdKLvuiX6BXib1AYLEXfVFUH0rBAMpch6VGLGkO8SysMg0RM4I8VSPHDRGlzdVZxc+ZDU5jjLXcVDBNCUTIk9WJ-VdhTnlyXJA5AA

    The above link has the "noLayout" option set to "true" here is the link with the layout applied : https://rtsys.informatik.uni-kiel.de/elklive/elkgraph.html?compressedContent=OYJwhgDgFgBA4gRgFABswE8D2BXALjAbRgGcBLALwFMAuGAZjoAYAaeugNhgF0kA7TACaUAyhUoA6AMaZexXOFK9cxWgCICAOQDyAEQCiAfQAyAQQBCeo8NYBZAJIa7NgKo2DwuwC09XVUiiklOAgklDoABJgvAIoisC0DgDCRs76BonhdkY6AEp6GkhgKMCYIKS4UAC2tKXA4pSSsRDEEpQoANbiaOhBlAJ8mEYYOLi0AGZFLQNCMNJKYIpBMADeSACQ3SOE62sQmGS4pDK0AEwsMGc7ZFSnAJzsrCe3jOs8a-xColRSMnIKSioYOptGlTBYrLYHE5XO4vD4-GsAkEwCEwpForFePEYEkUmkMllcvl1h8RGJxJVFKRKthqkCABR0E7iFgAFnYLIAlAi2p0IGABAI4moCLhMBAALwclgoShjXAShAs5gAI0wuDFlUVyrKwCgCqVjF862I-MkcXEpI0ghoMBeGzAKraMCMCDUc1wC14QVUKx2mzw2zWwb2ByOvFoCBOrNYAFYdmtrrbWQAOR7IYNvd42oZOlDEcQQNCSSiVShKEXhdL5AAqehyrAAagYa1oAAqsBwefTGtYAXxJNpgellZaUCD9wYD+AICdD5XDkdYTITSbuMZgsboOyzpK+Ejmfy9yhFIMMYMs1hg9kcLjcHm8vcRgWCoQiURiwpxGmSqUMBOyPICmDPdyUpXhqVpNR6ROFNlROaVuX9R1nSME41BHUty1wBBfVWYMHSwQNZwIxMxFoFMHguDMCPnQ5jjtOMEyzbMhFzNoCyLMASzHUYgQIKtElresmxbdtOw0bt4R2Ad+0HGZMN4k5J0IrYSJDfYFwYhBWBTeMCLXC5bg3WN7TWXcbX3H5ZHkY9AWBXRz3MS9IVvGEH2k4MkVfNEP0xbFcT-dJMkA4kQMssCqRpOlVBguCWBOAB2LkEQdPMXToDDR2wk48ITacgwM8iYEo9ME12TT6IjRiYHYZiE1Jdj80LYssIrfjBOEhsYGbVsO2-KSn1k2TSWHbKlDoFSCvUiqw201gEDofTg0Mp4N0SmiLM+clD1sxQT34s9jGciFryhO9YUfVLvJRN90U-LEEh-PF-xColgNYslvnAyCYri+DksYJCpxQlAXVZLK2twOg8oI6bysM0rqPKujFxquqCJYxrQc41reMrasNDrbrevEga7B7VLhvkygxqh1kpuGYi50qtGdIuRgMZW4q1t07dMx2UDvl2-4Doc0ETqvG9oXvOEnxu1F3wxL9AvxN6gMFiLvqiqCGVggGUuQ9KjFjSHeNZWGQaImcEeKpGThojS5uq84ufMhqcxxlruKhgmhKJkSerE-quwpzy5LkgcgA
    Laurent Redor
    @lredor
    I have to ask the question to find a part of the answer... With the option Crossing Minimization Strategy set to INTERACTIVE, the result is OK. But I think that even with LAYER_SWEEP value, the result should be the same. No?
    Laurent Redor
    @lredor
    image.png

    Hi,
    I think there is a problem with the scope of Node Label Padding. When this option is added to a node, it is not applied to the labels of this node but to the labels of the children of this node. Is it expected? I think not. And as said in the documentation: "Define padding for node labels that are placed inside of a node."

    Here is an example:

    • Node 1 has a specific node label padding but the default label padding is applied.
    • The parent of Node 2 has a specific node label padding but it is applied to the label of Node 2.
    Christoph Daniel Schulze
    @le-cds
    @omygoodness I cannot seem to reproduce your problems. I turned your input graph into the following graph model, which seems to work just fine:
    Christoph Daniel Schulze
    @le-cds
    @rk851 If all levels shared the same layout direction, this would probably not be too hard to do. In fact, ELK Layered already supports "levels". However, the fact that level 1 uses a top-down layout while level 2 uses a left-right layout would make this very hard. I think you'd be best served with a custom algorithm. As a side node, we aim at having a stand-alone edge routing algorithm available by the end of the year. You might be able to use that at some point.
    Christoph Daniel Schulze
    @le-cds
    @lredor Your list nodes might be best served by our Box Layouter or the Rectangle Packing algorithm. With the former, use the Priority option to order the rectangles. If you want to use ELK Layered, interactive or semi-interactive mode works, as you noted. However, I agree that it is confusing that crossing minimization doesn't necessarily keep an order which results in an optimal number of crossings. I thought there already was a ticket that tracked this issue, but I cannot seem to find it. My colleague did work on it for a while, I'll have to ask him.
    @lredor The label padding issue is in fact expected. Generally, all settings concerning spacings are defined on a parent node and apply to its children to make it easy to establish diagram-wide defaults. Defaults can be overridden for a specific node using the individual spacing override setting. I do agree, though, that the documentation could be improved. In fact, tickets eclipse/elk#335 and eclipse/elk#105 already track related issues.
    omygoodness
    @omygoodness
    image.png
    @le-cds It looks good but try to force position of this node which I pointed using 'elk.layered.layering.layerConstraint': 'FIRST' and then you will have multiple edges instead of one. Even though you used mergeEdges: true
    And this is my issue. Multiple edges are not merging properly
    Or maybe I did something wrong with my implementation :D
    omygoodness
    @omygoodness
    This node is connected to 4 nodes and it should merge this 4 edges into one but it is not happening
    image.png
    'elk.hypernode': true helps but it is messing around with too many nodes to use it.