-
Notifications
You must be signed in to change notification settings - Fork 52
Bugzilla ‐ Zest
It would be nice to have connection bendpoints. Perhaps this can be a connection style. GEF supports this so it should not be too much work.
Add the progress support to Horizontal Shift algorithm.
Zest seems to be requesting too much space when used inside a form. Opening this to investigate.
Build ID: I20070621-1340
Steps To Reproduce:
- Create a zest GraphViewer
- Attach a DropTargetListener
- Drag an object over the GraphViewer
In the dropTargetListener's dragOver() and drop() methods, the event parameter (of type DropTargetEvent) doesn't have its item field set properly. This field is null, where in other jface viewers, it is set to the child element of the viewer that is being dragged/dropped over.
I am using the same code snippet to reproduce this as in Bug 200732
More information: This can be worked around by examining the event.x and event.y and doing a search of the graph's nodes to determine which object is actually being hovered over. I do something like this, and call setEventItem() before I query event.item:
private void setEventItem( DropTargetEvent event )
{
List nodes = viewer.getGraphControl().getNodes();
for ( Object nodeObj : nodes ) {
GraphNode gn = (GraphNode) nodeObj;
Point location = gn.getLocation();
Dimension size = gn.getSize();
Control displayControl = null;
org.eclipse.swt.graphics.Point map =
gn.getDisplay().map( viewer.getControl(),
displayControl, location.x, location.y );
if ( (map.x < event.x) && (map.y < event.y) &&
(map.x + size.width > event.x) &&
(map.y + size.height > event.y) ) {
event.detail = DND.DROP_COPY;
event.item = gn;
return;
}
}
}
The labelSize field in GraphNode is not used by anyone. This can be removed.
Some useful methods, such as addNode, removeNode, addRelationship, removeRelationship (and possibly others, unless they're specifically meant to be non-API) should be made API -- declared in a class/interface in an exported package (e.g., re-declared in GraphViewer). Currently they're not visible to the outside world due to package access restrictions on the plugin.
Created attachment 78024 Proposed changes to support drag support customization.
With a few relatively minor changes, the application could customize the mouse drag behavior, e.g., to support only left-button dragging and creation of connections using the right mouse button. I've attached a patch with the proposed changes (including a few other minor enhancements). I'd be happy with an alternative solution that would accomplish the same. I look forward to your feedback. Thanks!
Zest connections styles should be changeable after the connections have been created. Opening to investigate.
When using a layout filter, it is important to get the GraphNode or GraphConnection, however, in Zest the actual layout node / arc are anonymous inner classes. We need to expose a way to get the node / connection in the filter.
The connection label is always in the center (between src and dest). This is fine in most cases, however, sometimes it should be cloesr to one end or another. A setLabelLocation(double pos), where 0 <= pos <= 1 should suffice.
Using 0.5 Zest and 3.2.2 GEF, currently the code responsible for the creation and resizing nodes (width, height) in the layout algorithms (particularly Spring Layout Algorithm) ignores the label or text associated with that node.
This leads to objects / nodes being created or resized whose labels are not longer visible or clearly visible. It would be nice to have the node only resizing to the smallest or most appropriate size that still allows for the text to be read / visible.
A code snippet should be added that shows how to use style providers.
Currently, when laying out nodes under any settings, the TreeLayoutAlgorithm determines node size and layout based on a pre-determined fixed canvas size. It would be very helpful to have tree layout determine ideal size given ideal node size and separation and determine canvas size from that.
Workaround:
Override TreeLayout with:
protected void preLayoutAlgorithm(InternalNode[] entitiesToLayout,
InternalRelationship[] relationshipsToConsider, double x, double y, double width,
double height) {
int maxDepth = contentProvider.getMaxDepth();
int attributeCount = contentProvider.getAttributeCount();
super.preLayoutAlgorithm(entitiesToLayout, relationshipsToConsider, x, y,
attributeCount * m, [maxDepth] * n);
}
But it is difficult to determine max Depth and results are inconsistent.
Build ID: I20071213-1700
Zest: 1.0.0v20071218
When using radial, directed and horizontal shift layout managers on large graphs it would be handy to be able to control the minimal distance between nodes. Maybe using a property on LayoutAlgorithm or one of the abstract classes.
When GraphViewer is drawing directed connections and a connection exists in both directions, then the labels of the two connections will (may) overlap. This was with SpringLayout, and the viewer was created like this:
viewer = new GraphViewer(parent, SWT.NONE); viewer.setContentProvider(new ViewContentProvider()); viewer.setLabelProvider(new ViewLabelProvider()); viewer.setLayoutAlgorithm(new SpringLayoutAlgorithm(LayoutStyles.NONE)); viewer.setConnectionStyle(ZestStyles.CONNECTIONS_DIRECTED); viewer.setNodeStyle(ZestStyles.NODES_NO_LAYOUT_RESIZE);
Make it possible to fix the layout in Zest, that will prevent users to move the boxes around.
Support is required for weighted tree layouts in zest (and perhaps in a general form Weighted Graphs). That is where the edge length is proportional to a specified weight or distance between nodes. For example such support would allow the display for phylogenetic trees (http://en.wikipedia.org/wiki/Phylogenetic_tree). Support for right-angled connections between nodes would also be required for certain styles of phylogenetic tree.
The first step would be to extend the GraphConnection class to a WeightedGraphConnection class that has the additional field 'weight' of type double.
I propose that there at least 6 (perhaps more) styles of WeightedTreeLayout.
- horizontal, straight connections
- vertical, straight connections
- horizontal, right-angle connections
- vertical, right-angle connections
- radial (see http://en.wikipedia.org/wiki/Image:MyosinUnrootedTree.jpg)
- radial, but with a circular connections (see http://en.wikipedia.org/wiki/Image:Tree_of_life_SVG.svg)
In the case of unrooted trees there would be many ways to draw a single tree. You would need to decide on start point for drawing (a defacto root). In calculating a layout I think that the first step would be to calculate maximum total weight from the root to a leaf node and use this to determine the scaling relative to the size of the display.
There's a problem with the "find the item under the mouse" snippet. It will work, but not with scaled layouts. The coordinates need to be translated.
Moreover, why should I care about the figure? In most cases, I need the node. There's no simple way of reaching the node from the figure anyway, since the figures mapping is private.
Let me suggest the followin method for the Graph class:
public GraphItem getItemAt(final int x, final int y) { GraphItem result = null; final Point point = new Point(x, y); getRootLayer().translateToRelative(point); final IFigure figureAtPoint = getFigureAt(point.x, point.y); if (figureAtPoint != null) { result = getGraphItem(figureAtPoint); } return result; }
When using Fisheye nodes, the fisheye figure should be removed before changing the graph layout. Otherwise, this may result in a fisheye figure floating while the graph changes under it.
Note that this does not happen for dynamic graphs.
Possible solution would be to add something like fishEyeLayer.removeAll();
At the begining of the applyLayoutInternal() of the Graph class.
Suggesting an enhacement: add the ability to add a listener that will receive an event when the layout is complete (after the animation). This could be useful for things like centering the graph in the view container, adjusting the zoom, etc.
Build ID: I20080617-2000
Steps To Reproduce: I'd like to use GraphContainer, but do something different for open() and close(). I can override those methods, but I cannot reduce the size of the container. computerContainerSize() is private and can't be overridden, and the constants it uses for minimum height and width cannot be changed.
Here is the relevant code:
private static final int MIN_WIDTH = 250;
private ContainerDimension computeContainerSize() { ... if (labelWidth < MIN_WIDTH) { labelWidth = MIN_WIDTH; expandGraphLabel.setPreferredSize(labelWidth, labelHeight); } if (labelHeight < 30) { labelHeight = 30; } ... }
It would also be useful to be able to access the private expandGraphLabel member, but that wouldn't be necessary if the GraphContainer's open and close methods handled the common actions (such as setting the expanded state) and then called an overridable function to do the customizable stuff.
More information:
When several items are selected, and one of them is clicked, no events are dispatched. Linked views, e.g. a properties view that displays details for the first element of a selection, are not notified and thus cannot be updated. The attached patch moved the last clicked element to the top of the structured selection and dispatches an event.
Build ID: I20080617-2000 Similar to bug 154579
Steps To Reproduce:
-
Decide to implement custom figure (such as an oval) in a Zest graph.
-
Since an oval is only slightly different from the default GraphLabel's rounded rectangle, you want to subclass it and override paint() and adjustBoundsToFit().
-
Unfortunately, GraphLabel is in the zest.core.widgets.internal package, which isn't exported from the Zest core JAR.
I think Zest not only needs the ability to implement custom figures easily, but it should also be easy to modify the existing figures so that we don't need to implement all the common internal chores.
Bug 242920 - Zest does not permit easy subclassing of GraphContainer to customize open/close methods
Build ID: I20080617-2000
Steps To Reproduce: I'd like to subclass GraphContainer and do different actions on open/close. I can override the GraphContainer's open() and close() methods, but I cannot easily set the container's ExpandGraphLabel (because it's in the zest.core.widgets.internal package, which isn't exported from the Zest core JAR).
It'd be great if the container handled opening and closing the ExpandGraphLabel and let a derived class override open() and close() to perform custom actions.
More information: The open/close ActionEvents come from the embedded Clickable object, so the listener gets only that object. It's hard (if not impossible) to obtain from that the class derived from GraphContainer. So, I implement my class's own add-listener method which adds this object as the Clickable's listener. When it gets an event, it turns around and fires it at the original object that added my class as a listener. That doesn't seem very efficient.
Ideally, the event that comes from the GraphContainer will inform the listener of the node that was clicked and the state it's now in (open or closed).
Build ID: I20080617-2000
Zest use a ContentProvider to make GraphNode objects from business-model objects. (see the internal and "only-package-visible" org.eclipse.zest.core.viewers.internal.AbstractStructuredGraphViewer.addGraphModelNode(Object) method..).
It isn't possible to create a custom nodes instead of GraphNode class (i.e. instances of GraphContainer) using only business-model/content provider mechanism.
I think this should be possible through ContentProvider ...
Calling refresh(Object,boolean) on a GraphViewer does not refresh the labels, because the method internalRefresh(Object, boolean) was not overridden. The attached patch fixed that problem.
Created attachment 113228 image of correct and buggy graph display
Build ID: I20080617-2000
Steps To Reproduce:
- Create a 'Hello World' RCP app
- Create a view using a Zest GraphViewer and add this view to the perspective so that it will be displayed on start up.
- For the content provider to the viewer, create a graph with 1 central node connected by to four others. (i.e., 5 nodes, 4 edges).
- Run the RCP app - sometimes the graph displays properly, sometimes nodes and edges are missing.
More information: This is from GEF newsgroup thread 'Re: strange zest rendering in RCP?' started 12/9/08.
I have discovered that it only seems to happen when the view appears from application startup. I have added a Window->ShowView action to the menubar, and if I close the graphview, and reopen it, the graph appears fine.
The model is 4 source nodes connected to a central destination node Node1 | | | Node2 ----> CentralNode<------Node 3 | | | Node4
When running from start up, the central node, 1 edge, and and 1 source node appear in the view, and another node with a self edge but no label. Two nodes are missing completely. I.e.,
A node -------------> CentralNode
Another_unconnected_node
This is actually pretty consistent - so the central node always appears, and 2 others. This is using the 'GraphViewer' class in a custom view class that extends ViewPart, and is contributed via the plugin.xml, in exactly the same way as the 'Hello World' RCP view.
The 'createPartControl' method of the view: public void createPartControl(Composite parent) { viewer = new GraphViewer(parent, SWT.H_SCROLL | SWT.V_SCROLL);
viewer.setContentProvider(new ViewContentProvider());
viewer.setLabelProvider(new MyLabelProvider());
viewer.setConnectionStyle(ZestStyles.CONNECTIONS_DIRECTED);
viewer.setLayoutAlgorithm(new SpringLayoutAlgorithm(LayoutStyles.NO_LAYOUT_NODE_RESIZING));
viewer.setInput(getInput()); // hardcoded test model data
getSite().setSelectionProvider(viewer);
setPartName("SBML view");
}
MyLabelProvider is a simple implementation of IEntityStyleProvider
ViewContentProvider implements IGraphContentPRovider and returns a hardcoded content.
We are using Zest to show dependency graph in m2e and users asking to provide keyboard navigation trough the graph. I think it would make sense to implement such feature at the framework level. Thanks.
I'm trying to initialize a graph using the following line of code
new Graph(parent, SWT.NONE | ZestStyles.IGNORE_INVISIBLE_LAYOUT)
in an Eclipse editor but the following error is reported:
Could not open the editor: Invalid style being set on FigureCanvas
The problem seems to be that Zest is passing the style all the way to draw2d while it shouldn't.
Created attachment 120409 Remove ExtendedDirectedGraphLayout
Build ID: I20080617-2000
Steps To Reproduce: Currently the DirectedGraphLayoutAlgorithm disables functionality in DirectedGraphLayout that spreads out GraphNodes horizontally. This leads to a graph that has all the nodes in a single column.
More information: If DirectedGraphLayout is used instead of ExtendedDirectedGraphLayout then, for my usage at least, the layout is better. If there is a need for ExtendedDirectedLayout maybe the constructor to DirectedGraphLayoutAlgorithm could have an extra parameter?
I've attached a patch that simply removes ExtendedDirectedGraphLayout, if something more intelligent is wanted let me know.
Build ID: M20080221-1800
Steps To Reproduce: How to set a Image to the Background of Zest Graph. This is not possible.
More information:
Build ID: 3.3
Steps To Reproduce: I can able to place my custom figure on my graph... The Same figure i cant able to display in th GroupContainer
More information:
Build ID: GEF-zest-sdk-3.5.0M4
Steps To Reproduce: Download Zest examples, disable dependency to org.eclipse.ui.workbench and run any of the JFace snippets. They will fail with a NoClassDefFoundError, because of missing dependency to IDisposable:
java.lang.NoClassDefFoundError: org/eclipse/ui/services/IDisposable
IEntityStyleProvider is used e.g. in class GraphItemStyler, which in turn is used in class AbstractStylingModelFactory.
More information: I would like to use Zest in a pure SWT/JFace or even Swing application, which should be possible, as there are working examples even in Zest source code (ok, the SimpleSWTExample needs org.eclipse.core.commands and org.eclipse.equinox.common, but that is just the example). When using JFace viewers, IEntityStyleProvider pulls in a dependency on org.eclipse.ui.services.IDisposable, which is contained in plugin/jar org.eclipse.ui.workbench_.jar. Requiring 4MB of code for a single interface qualifies as a bug in may opinion...
The horizontal placement of the nodes is removed by manually positioning. This does not seem to work properly.
http://www.eclipse.org/newsportal/article.php?id=21488group=eclipse.tools.gef#21488
Created attachment 130651 DirectEdit feature for Zest
There isn't any feature for DirectEdit. I have developed the feature for Zest and create a patch. (Test it on Vista and Fedora 10)
In this bug I'll provide changes necessary to use new layout API provided in bug 283083. I've also let myself clean the code a bit (remove commented and unused code, simplified some unnecessarily complex fragments).
New layout API provided in bug 283083 requires some changes in Zest snippets. It's also a good opportunity to give the snippets more meaningful names.
I tried to use nested containers with the JFace API in Zest 1.1. But when displaying the nodes, every subnode is presented in a single line.
The same behaviour can be observed with the GraphJFaceSnippet7.java snippet from the CVS.
My suggestion is twofolds: first, it would be great if there would be a solution to define the sublayouts (if it is possible, then please tell me, how, I couldn't find it); second, if no layout is set to the composite node, the layout of the graph viewer could be applied.
Noticed when using TreeLayoutAlgorithm and RadialLayoutAlgorithm.
This bug is reproducable using the example applications includes in the "Simple Swing Example included with the Zest source:
org.eclipse.zest.layouts.exampleUses.SimpleSwingExample.java
- Run the application.
- Click "Radial".
- Note that the nodes at the bottom of the graph are drawn closer to the containers edge than those at the top. The graph is off centre on the Y axis. Also note that this does not occur on the X axis.
Graphs appear shifted down the Y axis. In some cases this shift can cause nodes to be drawn outside of the bounds given to the layout algortihm.
The same shift can be seen when using the TreeLayoutAlgorithm. It is not seen using FlowLayout or GridLayout.
I have traced this problem back to the function AbstractLayoutAlgorithm.adjustNodeSizeAndPos(...) where removing the call in the else {} block to node.setInternalLocation() appears to solve the problem.
Unfortunately I don't know the context behind the logic used in this function so I can't say for sure whether my fix is the best solution, but it seems to work for the cases I have tested so far.
If this is the correct fix I believe the code is also broken for the X axis in cases where widthToHeightRatio is < 1.0. A similar fix should be applied there.
When you dispose() a node within the graph, the node could currently remain in the selectedItems list. This causes the SWTException below the next time anyone clicks in the graph.
The selectedItems is private and can't be accessed externally, so the workaround is to call graph.setSelection(null) before disposing any node.
!ENTRY org.eclipse.ui 4 0 2010-05-27 11:52:53.734 !MESSAGE Unhandled event loop exception !STACK 0 org.eclipse.swt.SWTException: Widget is disposed at org.eclipse.swt.SWT.error(SWT.java:4083) at org.eclipse.swt.SWT.error(SWT.java:3998) at org.eclipse.swt.SWT.error(SWT.java:3969) at org.eclipse.swt.widgets.Widget.error(Widget.java:467) at org.eclipse.swt.widgets.Widget.checkWidget(Widget.java:340) at org.eclipse.swt.widgets.Widget.getStyle(Widget.java:664) at org.eclipse.zest.core.widgets.GraphNode.getStyle(GraphNode.java:670) at org.eclipse.zest.core.widgets.GraphItem.checkStyle(GraphItem.java:112) at org.eclipse.zest.core.widgets.GraphNode.updateFigureForModel(GraphNode.java:758) at org.eclipse.zest.core.widgets.GraphNode.unhighlight(GraphNode.java:471) at org.eclipse.zest.core.widgets.Graph.clearSelection(Graph.java:724) at org.eclipse.zest.core.widgets.Graph.access$3(Graph.java:719) at org.eclipse.zest.core.widgets.Graph$DragSupport.mousePressed(Graph.java:690) at org.eclipse.draw2d.Figure.handleMousePressed(Figure.java:887) at org.eclipse.draw2d.SWTEventDispatcher.dispatchMousePressed(SWTEventDispatcher.java:214) at org.eclipse.draw2d.LightweightSystem$EventHandler.mouseDown(LightweightSystem.java:513) at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:185) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1052) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:4066) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3657) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2601) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2565) at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2399) at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:669) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:662) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:115) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:369) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:48) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:600) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:619) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:574) at org.eclipse.equinox.launcher.Main.run(Main.java:1407) at org.eclipse.equinox.launcher.Main.main(Main.java:1383)
Created attachment 170310 patch from git repository for zest.core
We have made use of GraphContainer for displaying composite nodes in our graphs. However, certain functions of the current implementation, most specifically moving nodes when expanding a composite, are not suitable for our use hence we have extended the class to our own ends.
This has involved the following changes:
-
Make pack public so it can be overrided and avoid moving nodes up/down
-
Make moveNodesUp and moveNodesDown public so they can be overridden
-
isExpanded getter so other components know when node is open/closed
-
Since getScale() is not supported in AspectRatioFreeformLayer, changes getScale() to getScaleWidth() and getScaleHeight(). Likewise, for setScale.
-
computerContainerSize() assumes childAreaHeight remains the same. If the container height is altered then it cannot be reduced. Change ensures that it has a minimum height but allows for the height to be reduced.
-
refreshLocation() is called after the size of the container has been set, which potentially puts the size of the GraphContainer out of sync with the size of the figure. This causes problems with resizing. Thus, fix to set the size of the GraphContainer to match the figure.
Couple of other fixes have been added to the patch too. These have been implemented in our internal project. More consideration may be required if other contributors find them problematic.
Patch has been attached.
Thanks
phantomjinx
The ZoomContributionViewItem.createCombo() method does not select any item in the combo by default. As a result, if you use ZoomContributionViewItem on a view toolbar, the combo appears blank by default and does not tell you what the current zoom level is.
Fix: Copy the lines from refreshCombo() that select an item in the combo.
Workaround: Since the methods and field are private, you can't workaround by subclassing. Instead, you can wait until the view is visible and then poke the class: xyz.asyncExec(new Runnable() { public void run() { toolbarZoomContributionViewItem.zoomChanged(1); } });
I've been trying to get basic keyboard navigation (e.g. tabbing) working with Zest. I was surprised to find many of the basics already implemented by draw2d, but unfortunately things aren't working at all in the Zest layer. The two most obvious problems I've found so far:
-
there is no focus indication on the default node or connection figures, so even though they can get focus there is no way to tell in the UI.
-
the ZestRootLayer reorders the nodes and connections when they are highlighted/selected! As a result, the tabbing order changes completely on every selection. If you select a node to start tabbing it gets put at the end of the list - so no matter which node you start with, the next tab exits the view. Needless to say, this is extremely confusing to watch. It's like a list box where every time you select an item it jumps to the bottom of the list.
Zest is missing support for accessbility. The bug I just filed for keyboard support is a good example, but there is no support for high-contrast displays and there seem to be other issues blocking screen readers. Zest should be comparable to GEF editors in this regard.
Build Identifier: 1.1
When running Zest on a second monitor I got a thread access exception. Digging into the code revealed extensive use of Display.getDefault() rather than Display.getCurrent()
Reproducible: Always
Steps to Reproduce: 1.Fire up a zest application on a second monitor 2.Using a view that includes a graph viewer I get the exception firing as part of createPartControl 3.
After pressing ⌘A in a focussed GraphViewer all nodes are drawn as if they have just become selected. However, the selection provider of the GraphViewer does not notify its listeners that the nodes have been selected.
Build Identifier: M20090917-0800
The position of Labels in curved connections is not at the midpoint where it should be. This is because the MidpointLocator class will only return the midpoint between 2 points and a PolylineArcConnection contains several.
Reproducible: Always
So, for a project we're working on, we needed to extend SpaceTreeLayoutAlgorithm so that it wouldn't break if the tree to be built would be much larger than the graph it's built in and we also needed the algorithm to calculate the trees optimal size before laying all the nodes out. For this we needed to change the following methods: *moveNodeForward *moveNodeBackward *getAvailableSpace *maximizeExpansion from the inner class SpaceTreeExpandCollapseManager
But it's all fairly impossible to do with all those private inner classes. So, what I'm asking is that could all this be a little more open to other classes and packages?
If I set a custom anchor in selfStyleConnection, then, zooming does not work properly. It seems that scaling is not applied to the coords the anchor is set to after zooming (in/out).
I will append an example to reproduce this.
Build Identifier: Version: 3.7.2 Build id: M20120208-0800
When rows==1, and cols==1, and numChildren==1
the following snippet of calculateNumberOfRowsAndCols_square results in an infinite loop.
while (rows * cols > numChildren) {
if (cols > 1)
cols--;
if (rows * cols > numChildren)
if (rows > 1)
rows--;
}
Reproducible: Didn't try
Steps to Reproduce:
- It occurred upon launching eclipse when it opened a view containing a zest graph from the previous session. It appears the graph had no content. (zero nodes or connections.)
In order to support some hover functionality over the nodes and connections I need to know the GraphItem under the mouse. It seems that exposing the 'GraphItem getGraphItem(IFigure figure)' as public will allow me to do so efficiently.
Created attachment 239133 File showing the layout problem with a large number of nodes
I want Zest to layout my figures whilst it can assume it has an unlimited amount of space available for this layout.
Currently the layouts (e.g. radial, see screenshot) tries to put everything in the available window.
Is this solvable in some way?
Created attachment 259233 Tooltip displayed incorrectly
We use a custom figure (which extends org.eclipse.draw2d.Figure) with a couple of labels as a tooltip for the Zest Graph nodes. It works in the Eclipse main window, tooltips are displayed correctly. As soon as a user moves the Zest graph to a separate window all tooltips are displayed behind the window, see attachment.
Hi ZEST experts,
I can see that GraphLayoutConnection#setBendpoints is not implemented. See:
public void setBendPoints(LayoutBendPoint[] bendPoints) { // @tag TODO : add bendpoints }
Is there a reason why this is not implemented? Would it be much work? I am willing to contribute. Could you please give some hints how I could start analyzing the issue? Would you generally accept this contribution?
With best regards, Tobias
Created attachment 260052 Simple test class for reproducing the exception
Steps to reproduce:
- Create a display and add a shell
- Add a graph to a shell
- Add a container
- Add two nodes inside the container
- Add a connection between the nodes
- Set curve depth to the connection
- When you try to dispose the display, NullPointerException is raised
More information: This only happens if the nodes are connected with a curved connection inside the container. If the connection is straight or there is no container it works fine.
The problem in the removeFigure() method of GraphConnection.java
If you don't set the curveDepth then this.connectionFigure.parent is set to null, this.targetContainerConnectionFigure.parent and this.sourceContainerConnectionFigue.parent point on the same object(Container)
However if you set the curveDepth then for some reason the this.connectionFigure.parent also points to that same object(Container) and the exception is raised when called
sourceContainerConnectionFigure.getParent().remove(sourceContainerConnectionFigure);
Exception in thread "main" java.lang.NullPointerException at org.eclipse.zest.core.widgets.GraphConnection.removeFigure(GraphConnection.java:159) at org.eclipse.zest.core.widgets.Graph.removeConnection(Graph.java:979) at org.eclipse.zest.core.widgets.GraphConnection.dispose(GraphConnection.java:176) at org.eclipse.zest.core.widgets.Graph.release(Graph.java:773) at org.eclipse.zest.core.widgets.Graph.access$6(Graph.java:763) at org.eclipse.zest.core.widgets.Graph$5.widgetDisposed(Graph.java:216) at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:123) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84) at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4362) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1113) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1137) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1118) at org.eclipse.swt.widgets.Widget.release(Widget.java:822) at org.eclipse.swt.widgets.Composite.releaseChildren(Composite.java:891)
I am using Zest containers to visualize state graphs. In my special case when the graph is disposed and all the widgets get disposed too, a NPE is thrown for each connection that is disposed.
A simple setup to reproduce is a (Zest)Graph, a GraphContainer widget in that graph, and inside that graph container two GraphNodes. A GraphConnection connects the nodes inside the same container.
The NPE: When the disposing process reaches the GraphConnection, at some point org.eclipse.zest.core.widgets.GraphConnection.removeFigure() is called. The connection as well as the source node and target node a members of the same container. therefore the fields connectionFigure, sourceContainerConnectionFigure and targetContainerConnectionFigure point to the same object.
The connectionFigure is removed from its parent, which leads to the NPE when trying to remove source- and targetContainerConnectionFigure from its now null parent.
Thanks for taking a look at it.
In computeForces(...), distance_sq can be 0 due to a wrong order of statements, which results in NaN forces in the following divisions by distance_sq. As a result, the algorithm sometimes places all nodes at (0, 0).
This problem was fixed when the code was revised for GEF4 Zest, but is still present in GEF 3/Zest 1.
Test based Graphical UIs are not styled correclty in the Dark Theme of Eclipse. The canvas is still light white and not dark.
Registering a CSS for stlying like: https://git.eclipse.org/c/platform/eclipse.platform.ui.git/tree/bundles/org.eclipse.ui.themes/css/dark/e4-dark_globalstyle.css
that contains
Graph { background-color:#515658; }
would be sufficient at least to make the canvas dark. Do you still fix such things in legacy?
Created attachment 280050 Wrong display in outline
We use ScrollableThumbnail to display that in the outline view for a org.eclipse.zest.core.viewers.GraphViewer.
On macOS 10.14 we see the content of that graph multiple times.
The arcs in the nested viewer cover the nodes and often look out of place. Since this is a nested viewer this is not an easy thing to fix. I am opening this bug report to discus solutions to this problem and experiment with ideas.