tomnelson / jungrapht-visualization Goto Github PK

Hi, and congrats to this repo, which fits a much needed space imho.. and it seems to work very so far.

I have a hard time finding any examples showing how to render vertices as shapes (rounded rect, rect, ...) with a line of text centered on that shape.

Could you point me to one or even provide one ?

Hello!
Can you explain please how frequent are releases?
When'll be the next one with ForceAtlas2?

Thank You!

Improve the performance and the visual effect of the SugiyamaLayoutAlgorithm using the techniques defined here:

An Efficient Implementation of Sugiyama’s Algorithm for Layered Graph Drawing
Markus Eiglsperge, Martin Siebenhaller, and Michael Kaufmann

This would be a new LayoutAlgorithm, not a replacement.

Develop an Orthogonal layout algorithm. Get rid of the legacy orthogonal edge drawing code, replacing it with articulated edges drawn using the same approach as the Sugiyama layout.

Put back code to create undirected graph, then MST to find roots and layout the graph.
Add test demo.

Hi,
Thumbs up for your library, it's a great piece of work!
Something I notice is that everytime I run the Sugiyama algorithm on exactly the same graph, the layout is different (or can be different) on each run compared to the previous run.
I assume it has to do something with the fact that the vertices in JGraphT are stored in a Set and not in a List, so retrieval of graph nodes is always in an undeterministic order.
Is there a way or would it be possible to provide functionality to calculate the layout in a deterministic way, so that every run the location of each vertex is exactly the same?
Best regards, Kristof

Hi,

First off all : great library, love it!

If I apply the TidierTree algorithm (layoutAlgorithm = TidierTreeLayoutAlgorithm), following piece of code works fine, and all locations are calculated

      LayoutModel<AbstractPlaceholder> layoutModel = LayoutModel.<AbstractPlaceholder>builder().size(1590, 1590).graph(placeholderGraph).build();
      layoutAlgorithm.visit(layoutModel);
      Map<AbstractPlaceholder, Point> locations = layoutModel.getLocations();

But if I use the same code for Sugiyama ((layoutAlgorithm = SugiyamaLayoutAlgorithm) or some other layout algorithms, then the locations list is empty, no locations are calculated

Based on the sample code, I managed to fix this by changing the code into

      VisualizationViewer<AbstractPlaceholder, DefaultEdge> vv = VisualizationViewer.builder(placeholderComputationGraph).viewSize(new Dimension(900, 900)).build();
      LayoutAlgorithmTransition.apply(vv, layoutAlgorithm, after);
      locations = vv.getVisualizationModel().getLayoutModel().getLocations();

So in theory this works fine now, but the annoying thing is that VisualizationViewer requires to run with headless mode = false (even if there is no interaction with UI, keyboard, etc)

The reason why the VisualizationViewer cannot run in headless mode, is that

• VisualisationViewer instantiates a DefaultGraphMouse on construction
• DefaultGraphMouse makes use of Modifiers.masks
• Modifiers.masks makes a call to Toolkit.getDefaultToolkit().getMenuShortcutKeyMaskEx();
• getMenuShortcutKeyMaskEx trows an exception if the application is running in headless mode

Maybe I overlook something, but it would be great if the Sugiyama algorithm would just work without using VisualizationViewer, or if VisualizationViewer or DefaultGraphMouse would work in a non-headless mode.

Thanks for your reaction and keep up the good work!

Hello!

Is there a way to get tree layouts to be laid out left-to-right instead of top-to-bottom?

Something along the lines of:

https://graphviz.org/Gallery/directed/ninja.svg

Hello!
Thank you for this nice library!

Can you please add a Getter for a mass (or make it public) in ForceObject?
I need it for implement a ForceAtlas2 (like in Gephi) because they use a "Repulsion by degree" conception and mass of objects (aka degree) must be used in implementation of ForceObject.addForceFrom method: https://journals.plos.org/plosone/article?id=10.1371/journal.pone.0098679

Many thanks in advance!

View Lenses are all elliptical, however a rectangular shape may be a better effect for the magnification view lens. An approach would be to make the lens shape settable and have all view related code respond to the actual lens shape instead of assuming a radius of an elliptical lens.

Fix the edge label rendering so that a label for an articulated edge is placed on the first segment

Normal scaling affects the layout positions only when scale is > 1.0 and affects the view (telescope effect) when scale is < 1.0.
When single axis scaling is enabled (CTRL or ALT button with mouse wheel) the view will do the same and squish the vertices.
Perhaps single axis scaling should apply only to the layout transform.

Improve testing and integration of Longest Path algorithm (in GraphLayers.longestPath).
Ensure that implementation is correct and that it creates correct-looking graph layouts

Apply wave-front technique to reduce edge-crossing in CircularLayoutAlgorithm

Current Graph Vertex Clustering support depends on unfortunate manipulation of the generic vertex types. Add support that is more flexible and usable for any type graph without changing the vertex generic type.
Replace the current demo.

Currently, there are two approaches to horizontal coordinate assignment, one using the graph layers array and pre-calculated 'position' values, the other using a DAG with edges along each layer (compaction graph). If the compaction graph approach is determined to be 'correct' and efficient, replace the graph layers array approach with it and remove the extra metadata (pos) from the delegate vertices (LV).