-
Notifications
You must be signed in to change notification settings - Fork 52
Bugzilla ‐ Draw2D
I am using the algorithm with all the default settings. For many graphs, I notice a crossing of the edges that should be avoided. I am including one example of a graph in the dot format. I can send more examples, including pictures.
digraph graph2 { PE727 -> PE729 PE725 -> PE727 PE721 -> PE725 PE716 -> PE721 PE618 -> PE718 PE618 -> PE717 PE618 -> PE715 PE618 -> PE714 PE618 -> PE713 PE618 -> PE716 PE718 -> PE723 PE717 -> PE722 PE714 -> PE720 PE713 -> PE719 PE719 -> PE724 PE724 -> PE726 PE726 -> PE728 PE617 -> PE618 PE616 -> PE617 PE18 -> PE500 PE18 -> PE341 PE18 -> PE99 PE18 -> PE616 PE500 -> PE503 PE500 -> PE502 PE500 -> PE501 PE503 -> PE507 PE507 -> PE509 PE509 -> PE579 PE509 -> PE576 PE509 -> PE573 PE509 -> PE572 PE502 -> PE506 PE506 -> PE508 PE508 -> PE578 PE508 -> PE575 PE508 -> PE571 PE508 -> PE569 PE501 -> PE504 PE504 -> PE505 PE505 -> PE577 PE505 -> PE574 PE505 -> PE570 PE505 -> PE568 PE341 -> PE348 PE341 -> PE347 PE341 -> PE346 PE341 -> PE343 PE341 -> PE342 PE341 -> PE349 PE349 -> PE353 PE353 -> PE366 PE366 -> PE367 PE352 -> PE366 PE348 -> PE352 PE351 -> PE366 PE347 -> PE351 PE350 -> PE366 PE346 -> PE350 PE345 -> PE366 PE343 -> PE345 PE344 -> PE366 PE342 -> PE344 PE99 -> PE102 PE99 -> PE101 PE99 -> PE100 PE102 -> PE177 PE102 -> PE176 PE102 -> PE105 PE101 -> PE107 PE101 -> PE106 PE101 -> PE104 PE104 -> PE184 PE100 -> PE103 PE103 -> PE183 PE103 -> PE182 PE103 -> PE181 PE103 -> PE180 PE103 -> PE179 PE103 -> PE178 PE181 -> PE187 PE179 -> PE186 PE178 -> PE185 }
The plug-in that I am developing uses Java2D to perform the drawing. To enable the Draw2D use Java2D transparently, I am implementing the Graphics interface and plugging it in through an implementation of GraphicsSource and a modified (through subclassing) version of LightweightSystem. Our own code is depending on our specific implementation of Graphics interface to be able to use more advanced features of Java2D.
The above construction works just fine in previous stable versions of GEF/Draw2D for Eclipse 3.1. However with the latest versions it breaks due to the following code in DeferredUpdateManager:
void paint(GC gc) { SWTGraphics graphics = new SWTGraphics(gc); if (!updating) { /** * If a paint occurs not as part of an update, we should notify that the region * is being painted. Otherwise, notification already occurs in repairDamage(). */ HashMap map = new HashMap(); Rectangle rect = graphics.getClip(new Rectangle()); map.put(root, rect); firePainting(rect, map); } root.paint(graphics); graphics.dispose(); }
The above code creates directly an instance of SWTGraphics without using the GraphicsSource indirection and thus breaks the abstraction. A fix for this should allow the use of an alternative Graphics implementation.
Created attachment 139957 A patch that queues Runnable in an ArrayList instead of creating a RunnableChain
Build ID: M20080911-1700
Steps To Reproduce: In the class org.eclipse.draw2d.DeferredUpdateManager, Runnables are queued using a special inner class RunnableChain which basically produces a linked list of Runnables. When run is called on the head of the linked list, first run of its next element is called an then run on the runnable of the elment itself.
This produces very large stacks, for each element in the list, a new stack frame is created. Instead of the RunnableChain construct, a simple ArrayList can be used as queue which will be faster and use less memory.
Fixed via https://github.com/eclipse-gef/gef-classic/pull/800
If you change system setting with ControlPanel when you have logic editor and its palette open, the color of figure created by ToolEntryEditPart remains as it is. From the accessibility point of view, this would be violation. It is okay for logic editor because it is a sample implementaiton but I am also usinng ToolEntryEditPart for my editor implementation.
The figure uses ColorConstatnts for its foregournd, background, border color, and so on. However ColorConstants fields are static and never flushed until you reload the class.
step:
- open logic editor and its palette
- open Winodows Control Panel -> Display Setting -> Design
- change the setting to High Contrast #1
- new color setting is applied dynamically to most windows on your screen
- logic editor and its palette remain as they were
Bug 54927 - VerticalPlacement should take a flag in it's constructor that determines whether the height of the nodes should be changed
Currently org.eclipse.draw2d.internal.graph.VerticalPlacement will resize the height of the nodes to be the height of the biggest node in the row. This behaviour should really selectable. I suggest adding a boolean flag to the constructor to enable or disable this behaviour.
It would be a useful feature to support a native ordering for nodes in the graph layout. Thus, any nodes would be laid out according to an ordinal assigned to each node. (e.g Node.order = 1,2,...n etc) The algorithm would try to perserve the ordering of the nodes provided no other conditions are broken such as crossed paths.
It would even be nicer if the we could specify that the order be absolutely preserved even if paths are crossed...as an optional control parameter to the algorithm.
remove the virtual node class and just convert long edges to multiple edges with a chain of normal nodes. This simplifies some of the other code which currently checks for v-node cases.
compound directed graphs are not optimized correctly because the subgraph containment edges are counted as false crosses. A local optimizer which understands when nodes are not swappable would improve output.
anchors fire moved when the parent's size is changed, and when common ancestors fire changes.
As the subsequent calls to the getBounds will return different values. This is an issue in the cases when a handle is hanged on the line ends.
-
In Viewport class method validate() does: super.validate(); readjustScrollBars();
-
In FreeformViewport method readjustScrollBars() is overridden and calls ff.setFreeformBounds(bounds); effectively changing contents bounds (it's bounds got changed and bounds of the nested freeform children too).
-
Method setBounds() in Figure class invalidates the figure (maybe it should revalidate it?) so contents figure is invalid and there is no request to validate it.
Consequences:
-
We have invalid figures in hierarchy though update was performed; is it fine?
-
If there are normal (not freeform) figures in contents that depend on contents bounds (say stripes that partition the diagram somehow or a label that should be at the right-bottom corner of the diagram) then they won't be updated since their parent (contents figure) is not validated and layout is not performed.
Asking a flowpage for its preferred size (before an update begins) causes it to add itself to the invalid figures. Then, the FigureCanvas gets sized, which adds the root figure to the invalid figures. Next, the FlowPage restores its old recommended width first, then the root gets resized, and the flowpage must layout again. It's pretty wasteful.
Possible fixes:
- don't use updatemanager's invalid figures or
- sort invalid figures prior to processing them. Partial ordering would be if a.contains(b), then a < b.
In the text example, I observed the following behaviours:
-
Ctrl + Left Arrow to navigate from one FlowFigure to another (eg., when changing from bold text to non-bold text) causes StackOverflowError.
-
Ctrl + Right Arrow does not work either, but it does not incur the Stack Overflow.
-
Using the down arrow key does not navigate to the next line.
Note that 1 and 2 work just fine if not using the Ctrl key. That is, if you're navigating one character at a time instead of one word at a time, there are no problems.
I tried mirroring the CaretExample and the borders did not get painted as expected. I think maybe its fragment does not get the right bidi level or something.
It is difficult to serialize hierarchies of Figures to XML because many primitive classes do not conform to basic javabeans requirements (they lack simple getter/setter pairs for fields). This could be easily fixed with liberal use of the "Generate Getter/Setters" command by someone with the ability to commit to CVS.
To reproduce one example:
import org.eclipse.draw2d.geometry.Rectangle import java.beans.XMLEncoder import java.beans.XMLDecoder import java.io.ByteArrayOutputStream import java.io.ByteArrayInputStream
....
Rectangle inputRect = new Rectangle(50, 25, 100, 200);
ByteArrayOutputStream temporaryStream = new ByteArrayOutputStream(); XMLEncoder encoder = new XMLEncoder(temporaryStream); encoder.writeObject(inputRect); encoder.close();
byte[] buffer = temporaryStream.toByteArray();
XMLDecoder decoder = new XMLDecoder(new ByteArrayInputStream(buffer)); Rectangle outputRect = (Rectangle)decoder.readObject(); decoder.close();
if(!inputRect.equals(outputRect)) System.out.println("Not equal! Before: " + inputRect + " After: " + outputRect);
The rotate method of PrinterGraphics does not work properly. For example, in PrintFigureOperation.printPages(), add graphics.rotate(90); right before figure.paint(graphics);
You will see this error in the log !MESSAGE The class: class org.eclipse.draw2d.PrinterGraphics has not implemented this new graphics function !STACK 0 java.lang.RuntimeException: The class: class org.eclipse.draw2d.PrinterGraphics has not implemented this new graphics function at org.eclipse.draw2d.Graphics.subclassFunctionMission (Graphics.java:897) at org.eclipse.draw2d.Graphics.rotate(Graphics.java:702) at org.eclipse.gef.examples.logicdesigner.actions.RotatePrintGraphicalViewerOperati on.printPages(RotatePrintGraphicalViewerOperation.java) at org.eclipse.draw2d.PrintOperation.run(PrintOperation.java:155) at org.eclipse.gef.examples.logicdesigner.actions.LogicPrintAction.run (LogicPrintAction.java) at org.eclipse.ui.internal.PluginAction.runWithEvent (PluginAction.java:246) at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection (ActionContributionItem.java:538) at org.eclipse.jface.action.ActionContributionItem.access$2 (ActionContributionItem.java:488) at org.eclipse.jface.action.ActionContributionItem$5.handleEvent (ActionContributionItem.java:400) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:844) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3070) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2703) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:1699) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:1663) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench (Workbench.java:367) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:143) at org.eclipse.ui.internal.ide.IDEApplication.run (IDEApplication.java:103) at org.eclipse.core.internal.runtime.PlatformActivator$1.run (PlatformActivator.java:226) at org.eclipse.core.runtime.adaptor.EclipseStarter.run (EclipseStarter.java:376) at org.eclipse.core.runtime.adaptor.EclipseStarter.run (EclipseStarter.java:163) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:85) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:58) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:60) at java.lang.reflect.Method.invoke(Method.java:391) at org.eclipse.core.launcher.Main.invokeFramework(Main.java:334) at org.eclipse.core.launcher.Main.basicRun(Main.java:278) at org.eclipse.core.launcher.Main.run(Main.java:973) at org.eclipse.core.launcher.Main.main(Main.java:948)
TextFlow and related doesn't work for the selected text if antialiasing is on.
HorizontalPlacement calls normalize, which should place the layed out graph starting at x==0. But, there are some additional nodes inserted into the graph that capture the edges and their offsets on their respective nodes. These extra nodes have edges to real nodes with non-zero delta, which pushes the entire graph over in some cases.
the fix is to normalize only the real nodes in the graph.
The following automated tests in TextFlowWrapTest fail. They have been commented out for now.
// General tests doTest2(" foobar", "abc", " foobarab", new String[] {"", NEWLINE, "foobar"}); doTest2("abd", "\u7325", "abd", new String[] {"abd", NEWLINE, "\u7325"}); // soft-wrapping doTest2("foofoo", "foo", "foo", new String[] {"foo", NEWLINE, "foo", NEWLINE, "foo", TERMINATE}); doTest2("foofo", "ofoo", "foo", new String[] {"foo", NEWLINE, "fo", SAMELINE, "o", NEWLINE, "foo", TERMINATE});
The following tests in AdvancedGraphicsTests fail on at least one platform.
testInterpolation() testPathDraw() testPathFill()
They have been commented out for now and are most likely caused by bugs in SWT. Regardless, we should investigate the problems and open bugs against SWT.
A new step in the graph layout has been added called RouteEdges. This reuses the ShortestPathRouter algorithm. The problem is the calculation of neighboring obstacles is not correct in a compound graph. To see the problem run the CompoundGraphDemo and look at the initial test graph.
In certain cases, edges with virtual nodes are not properly handled during the layout process. They are never uninverted and thus point in the wrong direction.
I realize that the plan is to eventually eliminate the use of VirtualNodes during graph layout (Bug 72201), but the following modification could be made to fix the bug until that virtual node change is made.
Explanation of what is causing the bug and my fix:
org.eclipse.draw2d.graph.DirectedGraphLayout calls visit() for each of 11 different layout classes, and then calls revisit() for each of those same 11 layout classes, but in the reverse order.
In order to break cycles, the first visit method inverts edges so that they all 'point' in the same direction (so that there isn't an A->B edge and an B->A edge) and sets edge.isFeedback on all the inverted edges.
After ranks are assigned (during InitialRankSolver, TightSpanningTreeSolver, and RankAssignmentSolver), PopulateRanks.visit() adds VirtualNodes for all edges that span multiple ranks.
However, when PopulateRanks.visit() calls VirtualNodeCreation(), the isFeedback setting is not preserved, so inverted edges with virtual nodes are never uninverted. That was the bug.
Fixing it is more involved than simply preserving the isFeedback setting, because Draw2D does not provide a means to correctly invert edges with virtual nodes. Thus, for InvertEdges.visit(), it is necessary to NOT invert edges whose source or target is a VirtualNode, and TO unset isFeedback for those that can be inverted.
Then, at the very end of the list of classes when they are re-visited, during BreakCycles (which formerly didn't have a revisit() method), we invert all the edges which still have isFeedback set. These are all the edges that had been inverted and had VirtualNodes inserted (and thus were not un-inverted during InvertEdges.visit()).
We've seen this bug occur with as few as 3 nodes and 4 edges. E.g., nodes A, B, C, and edges A->B, B->A, B->C, C->A.
I've tested this fix with some rather complex graphs, and in every case thus far it has fixed the problem without introducing any new ones. The modified draw2d code is used by many others as well.
The files needing modification are BreakCycles and InvertEdges in org.eclipse.draw2d.internal.graph. In BreakCycles I've added an override for method revisit. I'll be attaching modified versions of these 2 files.
No way to expose advanced transformation capabilities at a draw2d level. API required to in Graphics interface to allow this.
the cursor is in a place, and the typed characters appear in another place.
Steps to recreate the problem:
- Create a file using the WYSIWYG example file wizard.
- Try inserting and deleting mixed Arabic and English text.
Expected bevaviour:
Typed characters and the curser should be in the same place.
Problem: the typed characters appear in a distance from the curser. please see the screen shot
Because super.dispatchMouseReleased(me); triggers creation of a new MouseEvent as currentEvent after dispatching the consumed state of the dispatched mouseevent is lost, hence draw2dBusy() will always return false.
The domain will receive the released event no matter what.
/**
- @see EventDispatcher#dispatchMouseReleased(org.eclipse.swt.events.MouseEvent) */ public void dispatchMouseReleased(org.eclipse.swt.events.MouseEvent me) { if (!editorCaptured) { super.dispatchMouseReleased(me); if (draw2dBusy()) return; } if (okToDispatch()) { setRouteEventsToEditor(false); domain.mouseUp(me, viewer); updateFigureUnderCursor(me); } }
I got StackOverflow error when rendering a big diagram with 2300 nodes and 3000+ connection lines. Unfortunately, this is a valid use case because my tool visualizes the legacy code which tends to be a huge monolithic program.
java.lang.StackOverflowError at org.eclipse.draw2d.graph.RankAssigmentSolver.depthFirstCutValue(RankAssigmentSolver.java:40) at org.eclipse.draw2d.graph.RankAssigmentSolver.depthFirstCutValue(RankAssigmentSolver.java:40) at org.eclipse.draw2d.graph.RankAssigmentSolver.depthFirstCutValue(RankAssigmentSolver.java:40) at org.eclipse.draw2d.graph.RankAssigmentSolver.depthFirstCutValue(RankAssigmentSolver.java:40) at org.eclipse.draw2d.graph.RankAssigmentSolver.depthFirstCutValue(RankAssigmentSolver.java:40) at org.eclipse.draw2d.graph.RankAssigmentSolver.depthFirstCutValue(RankAssigmentSolver.java:40) at org.eclipse.draw2d.graph.RankAssigmentSolver.depthFirstCutValue(RankAssigmentSolver.java:40) at org.eclipse.draw2d.graph.RankAssigmentSolver.depthFirstCutValue(RankAssigmentSolver.java:40) at org.eclipse.draw2d.graph.RankAssigmentSolver.depthFirstCutValue(RankAssigmentSolver.java:40) at org.eclipse.draw2d.graph.RankAssigmentSolver.depthFirstCutValue(RankAssigmentSolver.java:40) at org.eclipse.draw2d.graph.RankAssigmentSolver.depthFirstCutValue(RankAssigmentSolver.java:40)
Currently there is no way to set the line spacing for a block of text short of a somewhat elaborate construction that involves subclassing AbstractFlowBorder, TextLayout and TextFragmentBox.
Bug 160351 - [Text] Setting the layout manager on a text flow after adding to parent leads to a NullPointerException
When a layout manager is set on a text flow it must be done before adding the text flow to its parent otherwise a NullPointerException may result.
Example Application:
public class OrderBug extends org.eclipse.draw2d.examples.AbstractExample {
public static void main(String[] args) { new OrderBug().run(); }
protected void sizeShell() { shell.setSize(shell.computeSize(400, 200)); }
protected IFigure getContents() { Figure f = new Figure(); f.setLayoutManager(new ToolbarLayout()); f.add(orderBug()); return f; }
protected IFigure orderBug() {
final boolean die = true;
FlowPage fp = new FlowPage();
TextFlow tf = new TextFlow();
if (die) {
fp.add(tf);
tf.setLayoutManager(new ParagraphTextLayout(tf));
} else {
tf.setLayoutManager(new ParagraphTextLayout(tf));
fp.add(tf);
}
tf.setText("hello");
return fp;
}
}
In my excitement to use the latest, I am in the process of upgrading our project software from Eclispe 3.1.2 to 3.2.1. I encountered a problem that I have distilled in the attached example and output. I posted a message on the GEF newsgroup, but received no answers. I'm not sure if I'm doing the right thing in opening a bug, but here goes...
The example has a FigureCanvas in a Shell. The canvas has a root figure, and the root figure has 2 round rectangles. The example I have provided attempts to draw a transparent rectangle on the canvas. Drawing this transparent rectangle is as follows: when the user holds the left mouse button down and moves from point A to point B, the rectangle is drawn based on these 2 points.
The result using the 3.1.2 libraries is as expected - shown in FigureCanvasTransparencyWith_3.1.2_correct.png The result using the 3.2.1 libraries is clipped - shown in FigureCanvasTransparencyWith_3.2.1_incorrect.png, and the transparent rectangle is only partially shown over the 2nd child figure added.
Attached is also the source code for the snippet.
The same incorrect behavior is exhibited using 3.2.0.
Thank you! E.
Fan and SPC routers can't be used in conjunction because the SPCR invalidates certain connections in its route method. To prevent that from adversely affecting the router, it has an ignoreInvalidate field. When you use the two routers together, the fanned connections keep jumping around (their index changes), because of the invalidation happening in the route() method. What we need is for Automatic/Fan router to have the same ignoreInvalidate field which is set to true before next.route() is invoked, and set to false after it's done.
Really hard to see what area is selected. Suggest the following change to the selector figure. Also, a set method for the selector figure could be added to make it easier to extend.
private class SelectorFigure extends Figure { { Display display = Display.getCurrent(); PaletteData pData = new PaletteData(0xFF, 0xFF00, 0xFF0000);
/** The following change makes the figure darker, but still transparent **/ RGB rgb = display.getSystemColor(SWT.COLOR_BLACK).getRGB();
int fillColor = pData.getPixel(rgb);
ImageData iData = new ImageData(5, 5, 24, pData);
iData.setPixel(0, 0, fillColor);
iData.setAlpha(0, 0, 55);
image = new Image(display, iData);
}
Build ID: M20060629-1905
Steps To Reproduce:
- Run your draw2d app in Linux with a Hebrew locale selected (-nl iw)
- The figures are displayed the same way as they're in LTOR
More information: This does work correctly in Windows XP.
The width and height of rectangles or in methods that take width/height arguments seem to have two different meaning in different places in draw2d: a) The difference between the rightmost and leftmost (top and bottom) pixel coordinates. b) The actual width in pixels.
width (b) is 1 pixel greater than width (a) for the same screen display - e.g. for a rectangle consisting of a single pixel, (a) is 0 while (b) is 1.
Graphics.drawRectangle(), Rectangle.bottom() and Rectangle.right() use meaning (a) Graphics.fillRectangle() and clipping of figures use meaning (b)
import org.eclipse.draw2d.ColorConstants; import org.eclipse.draw2d.Figure; import org.eclipse.draw2d.Graphics; import org.eclipse.draw2d.IFigure; import org.eclipse.draw2d.LightweightSystem; import org.eclipse.draw2d.geometry.Rectangle; import org.eclipse.swt.widgets.Display; import org.eclipse.swt.widgets.Shell;
public class Main { public static void main(String args[]){ Shell shell = new Shell(); shell.setBackground (ColorConstants.white); shell.open();
LightweightSystem lws = new LightweightSystem(shell);
IFigure root = new Figure() {
@Override
protected void paintFigure (Graphics g) {
// drawRectangle draws 2x2 pixels (right = left + width) ...
g.setForegroundColor (ColorConstants.black);
g.drawRectangle (1, 1, 1, 1);
// ... but fillRectangle fills 1 pixel (right = left + width - 1)
g.setBackgroundColor (ColorConstants.black);
g.fillRectangle (5, 1, 1, 1);
// Rectangle.right() and Rectangle.bottom() are consistent with drawRectangle interpretation
Rectangle rect = new Rectangle (1, 1, 1, 1);
g.drawText (String.format ("[%s..%s, %s..%s]%n", rect.x, rect.right(), rect.y, rect.bottom()),
5, 10);
}
};
// clipping behavior is consistent with fillRectangle interpretation:
// the figure is clipped at 2x2 pixels
root.add (new Figure () {
private final Rectangle r = new Rectangle (20, 1, 2, 2);
@Override
public Rectangle getBounds () {
return r;
}
@Override
protected void paintFigure (Graphics g) {
g.drawRectangle (r);
}
});
lws.setContents (root);
Display display = Display.getDefault();
while (!shell.isDisposed ()) {
if (!display.readAndDispatch ())
display.sleep ();
}
}
}
SWTEventDispatcher.dispatchMouseReleased() looks like this:
public void dispatchMouseReleased(org.eclipse.swt.events.MouseEvent me) { receive(me); if (mouseTarget != null) { mouseTarget.handleMouseReleased(currentEvent); } releaseCapture(); receive(me); }
Because of that call to releaseCapture(), it doesn't matter if you call consume() on the event inside handleMouseReleased. In the GEF subclass, DomainEventDispatcher, it looks like this:
public void dispatchMouseReleased(org.eclipse.swt.events.MouseEvent me) { if (!editorCaptured) {
super.dispatchMouseReleased(me); if (draw2dBusy()) return;
}
if (okToDispatch()) {
setRouteEventsToEditor(false);
domain.mouseUp(me, viewer);
updateFigureUnderCursor(me);
}
}
draw2dBusy() never returns true after a mouse release, so the method will always continue and get propagated to the GraphicalEditor. If I have a figure on top of the graphical editor which is supposed to intercept all events, I don't want that to happen.
After I invoke the layout algorithm (i.e. DirectedGraphLayout), it reassigns the height and width to the node. This makes the graph look and feel inconsistent because all labels (I am drawing the nodes as Labels) now are of different sizes. As a result some of these labels wouldn't even contain the full text. Either:
- There should be a option to specify that the width and height shouldn’t be changed during the layout
- We shouldn’t preassign the width and height to the nodes and the layout should only take in the information about the available space and use it appropriately
Problem when adding a MouseMotionListener to PolylineConnection:
Having two AbstractGraphicalEditParts which are connected by PolylineConnection. One of these AbstractGraphicalEditParts is displayed over the second one.Mouse moves over the connection.
RCP application is not responding. The scrollbar of editor goes still to the right side.
Build ID: I20070608-1718
I have a polyline connection with polyline decorations using the defaults, except for a larger line width (5). The line shows up past the decoration, which looks bad and I don't believe is intended. I tried scaling the decoration, but that didn't help. I can post screenshots if that would be helpful.
Build ID: I20070625-1500
Steps To Reproduce:
- Create a Draw2D chart with one parent figure
- Add to this parent, a lot of children (10000)
- Observe the time spend in FocuseTraverseManager when a focuse event occurs in the SWT canvas containing the Draw2D chart
More information: After several discussions on the Gef-Draw2d mailling list, Randy Hudson told me that this is a known issue:
"There's an n2 performance issue in the way that lightweight system handle focus gained"
A simple workaround for this consists in telling the parent figure to be focusable. This way the FocuseTraverseManager stops to find a focusable focus on the first figure (the parent).
The steps field in DirectedGraphLayout is restricted to package level access. I would like to remove one of steps from the algorithm, but I can't access the list of steps (and this time i don't see an accessor method :)
+++ This bug was initially created as a clone of Bug #33568 +++
I have an image with a transparent background (16x16 icon) that is embedded in a draw2d Label figure. When the diagram containing this figure is printed (using a subclass of a draw2d PrintOperation), the image appears in the printout as a solid black square.
That greatly increases the potential of what the FlowBorder can do since it would have access to things such as the fragment's baseline (useful for underline borders).
Assigning to myself.
org.eclipse.draw2d.examples has a bunch of good example snippets, but they are not packaged and are not available as a download.
We should look at creating something like the SWT Examples.
Bug 213594 - SWTEventDispatcher: requestRemoveFocus called by removeNotify removes focus for any figure.
Build ID: M20070212-1330
Steps To Reproduce: When a figure is removed from its parent, it invokes the requestRemoveFocus method of the EventDispatcher. In case of the SWTEventDispatcher this results in the focus to be lost when the FigureCanvas loses and gains it's focus:
public void testDraw2D() { Shell shell = new Shell();
// setup
FigureCanvas figureCanvas=new FigureCanvas(shell, SWT.NONE);
Figure root = new Figure();
figureCanvas.getViewport().setContents(root);
Figure label1 = createFigureAndAdd(root);
Figure label2 = createFigureAndAdd(root);
Figure label3 = createFigureAndAdd(root);
// test
label2.requestFocus();
root.remove(label3);
//or figureCanvas.getViewport().internalGetEventDispatcher().requestRemoveFocus(label2);
System.out.println(label1.hasFocus() == false);
System.out.println(label2.hasFocus() == true);
figureCanvas.getViewport().internalGetEventDispatcher().dispatchFocusLost(null);
figureCanvas.getViewport().internalGetEventDispatcher().dispatchFocusGained(null);
System.out.println(label1.hasFocus() == false);
System.out.println(label2.hasFocus() == true);
shell.dispose();
}
More information: The current implementation of SWTEventDispatcher.requestRemoveFocus looks like this:
/**
- @see EventDispatcher#requestRemoveFocus(IFigure) */ public void requestRemoveFocus(IFigure fig) { if (getFocusOwner() == fig) setFocus(null); if (mouseTarget == fig) mouseTarget = null; if (cursorTarget == fig) cursorTarget = null; if (hoverSource == fig) hoverSource = null; getFocusTraverseManager().setCurrentFocusOwner(null); }
The last line should test if the figure that lost focus was the owner:
/**
- @see EventDispatcher#requestRemoveFocus(IFigure) */ public void requestRemoveFocus(IFigure fig) { boolean wasOwner = (getFocusOwner() == fig); if (wasOwner) setFocus(null); if (mouseTarget == fig) mouseTarget = null; if (cursorTarget == fig) cursorTarget = null; if (hoverSource == fig) hoverSource = null; if (wasOwner) getFocusTraverseManager().setCurrentFocusOwner(null); }
TextFlow creates border fragments for borders that have insets on the side. The layout for InlineFlow doesn't. So FlowBorders with side insets don't work properly with InlineFlows.
Bug 216621 - LightweightSystem's RootFigure should use Canvas#drawBackground instead of filling with BG color
I just came across the method drawBackground on Canvas. Currently draw2d takes whatever background color has been set on the widget and just fills it on the canvas. This is not very native nor consistent with SWT.
On the Mac, there used to be these ugly penal stripes that were "expected" to appear in certain situations. Yet when GEF was used in those scenarios, GEF would just fill with a solid color. There are probably still flavors of this in the latest Mac OS X, Windows Vista, and certain GTK themes.
Also, SWT added support for setBackgroundImage(image), and the ability to inherit backgrounds. Draw2d's canvas doesn't support these.
The alignment of a block, if not set, is derived from its ancestors. So, setting the alignment of a block, should cause the child blocks to re-layout (since their alignment could've also been affected). However, that doesn't work currently. So, if you have two nested blocks and you set the alignment of the parent block, the child block will not be updated (until the next layout happens).
Created attachment 102829 SplineCurveConnection class extending a PolylineConnection
The request is to add smooth curves to the list of available connections instead of polylines only. This could be bezier curves or cubic splines.
See attached my version of a cubic spline curve connection, which extends a PolylineConnection. It still has room for improvements but already looks quite nice. If interested you can use it.
Build ID: I20080523-0100
Steps To Reproduce:
- on a gmf diagram, use Zoom To Fit
More information: Zoom to fit, or any other function that wants to zoom to arbitrary new bounds has to use separate setZoom() and setLocation() calls, and it causes unnatural animation.
Instead of a direct straight-line shift, objects appear to follow an arc with a bend in it as the animation hands off from scaling to translation.
Bug 239053 - ManhattanConnectionRouter doesn't work properly with some anchor combination in the negative coordinates
Created attachment 106156 Routing result with the orignial algorithm
Steps To Reproduce: With anchor having negative direction, you may end up with the wrong point in your routing list. See shape 1 linked iwth 2 and shape 3 linked with 4 in the attached screen shot. Also, if a link pass close to the y or x axis, it wont cross it (see shape 5 linked with shape 6 in the attached screen shot).
More information: The problem is that the proper coordinates loose its appropriate sign because of the startDirection or endDirection. I've fixed the problem by keeping rays startOrientation and endOrientation which can only be (0, 1) or (1,0) and I use them with a dotProduct to eliminate the proper part (horizontal or vertical) of obtained ray. Before, this was done using startNormal.similarity, which didn't return the proper signs in all cases.
We need to provide the necessary support to ScaledGraphics / SWTGraphics to set gradients on figures.
Background gradients are supported by SWT, but GEF does not support them properly. We need to confirm but I think that SWTGraphics supports gradient but ScaledGraphics does not. And we need ScaledGraphics and zoom and printing support. See Bug 132361 and Bug 184651 and Bug 167461
Build ID: M20080911-1700
Steps To Reproduce: public class EditableFigureCanvasTest extends TestCase { private static final class TestUpdateManager extends UpdateManager { @Override public void addDirtyRegion(IFigure figure, int x, int y, int w, int h) {
}
@Override
public void addInvalidFigure(IFigure figure) {
}
@Override
public void performUpdate() {
}
@Override
public void performUpdate(Rectangle exposed) {
}
@Override
public void setGraphicsSource(GraphicsSource gs) {
}
@Override
public void setRoot(IFigure figure) {
}
@Override
public boolean isDisposed() {
return super.isDisposed();
}
}
@Test public void test_setUpdateManager() { //test if old updateManager is disposed Display.getDefault().syncExec(new Runnable() { public void run() { //test if bug still exists LightweightSystem lightweightSystem = new LightweightSystem(); TestUpdateManager um = new TestUpdateManager(); lightweightSystem.setUpdateManager(um); lightweightSystem.setUpdateManager(new TestUpdateManager()); assertFalse("bug is fixed, remove workaround",um.isDisposed()); } }); } }
To Produce a widget is disposed exception setup a canvas:
- create a canvas
- add an update listener to the UpdateManager
- access the canvas inside listener
- dispose canvas after replacing the UpdateManager
More information: If the widget is disposed after setting the new UpdateManager, the old UpdateManager is not disposed and will execute its pending updates and validations. This will result in a widget is disposed error.
Build ID: M20080911-1700
Steps To Reproduce:
- Install GEF
- Create some initial code
- Add the following code to some constructor of a class that inherits from RectangleFigure
More information: When creating a new Figure that inherits from RectangleFigure (works also with Ellipse, but only for example) and setting its Layout to DelegatingLayout, adding any LayoutManagers to children figures leads them to disappear. Example Code from a constructor:
setLayoutManager(new DelegatingLayout()); Ellipse miniEllipse = new Ellipse(); miniEllipse.setSize(new Dimension(7,7)); add(miniEllipse, new RelativeLocator(this, 0.5, 0.5)); Ellipse miniMiniEllipse = new Ellipse(); miniMiniEllipse.setSize(new Dimension(3,3)); miniEllipse.setLayoutManager(new DelegatingLayout());
If the last line is absent, everything works well. But when it's present, the inner Ellipse disappears (I don't know what happend to it).
Build ID: M20080221-1800
Steps To Reproduce: The ManhattanConnectionRouter which is provided by org.eclipse.draw2d provided a good basis for drawing connections in our tooling but it had problems in a few situations. If you take a look at the image in diagram1.jpg you will notice the problems it has in drawing the connection between Component1 and Component2 (it appears behind Component3). We prefer to draw the connection around Component3 as shown in diagram2.jpg.
You will also notice that the two connections between Component4 and Component5 and between Component4 and Component6 (in diagram1.bmp) have vertical portions which are very close to each other. We prefer to separate them more for clarity as shown in diagram2.bmp.
More information: In order to implement our desired connection layout, we created class SCDLManhattanConnectionRouter that was based on the original ManhattanConnectionRouter from org.eclipse.draw2d.
We would like to submit our implementation of the connection router (SCDLManhattanConnectionRouter) for consideration into the base eclipse code, and we are making our changes available as required under the Eclipse Public License. Please see the attachment called SCDLManhattanConnectionRouter.java for that implementation.
Created attachment 126969 My quick solution
Build ID: M20080911-1700
Steps To Reproduce: We're building a WYSIWYG editor using Draw2D. I'm missing the possibility of setting TextStyles (or equivalent) on a TextFlow. This would make it possible to use the underline-features (including SWT.UNDERLINE_ERROR for marking text by a spellchecker).
I already created a subclass of TextFlow (StyledTextFlow) on which one can add TextStyle objects on a specific range. To apply these TextStyles, I made an override of paintText(), but this method is called with substrings (the fragmented parts) so the offsets given for the TextStyles won't always match.
I also added basic support for sub-/superscript, by changing the y-coordinate when drawing the string. This currently has no effect on the line-height, so setting the baseline too high or too low, makes the string (partially) invisible.
I could make the necessary changes to the Draw2D source myself, but I don't want to change the Draw2D/GEF plugin, because that would mean extra effort when updating to new releases.
More information: Any other enhancement to Draw2D text which enables the rendering of subscript and superscript, and makes it possible to decorate text with SWT.UNDERLINE.ERROR are welcome, obviously.
even if a connector is invisible, it's layout still fills it's bounds rect with the visible boundary of the connection. this has the cosmetic effect of causing an editor's canvas to expand to empty space if the connection happens to go outside of the area where figures are.
if a connection is invisible, perhaps the bound's location should be set to the first point of the connection and its size set to 0,0
if a shape is invisible, it's bounds shouldn't be included in the bounds of the canvas
In the draw2d API the class AbstractBackground is an abstract class. It is used in the paintFigure() method of class Figure to check if the border of this figure is an abstract background border.
But what if I want to use a sub class of AbstractLabeledBorder and give that also the behavior of an abstract background?
This would be only possible if AbstractBackground is an interface.
BTW AbstractBackround has no functionality at all so converting it to an interface should be no problem; just add the missing getInsets() method implementation to the javadoc and explain why you should change it.
Probably creating an interface with a new name and deprecating the old class would be compatible to older implemenations.
Created attachment 139889 First patch to improve
As blogged here: http://manuelselva.wordpress.com/2009/05/06/draw2d-enhancements-part-1-labels-on-polylines/
it would be nice to have draw2d supporting "labeled" polylines.
I don't have enough time to make a clean patch and as suggested by Mariot I am putting here a FIRST patch for such feature. WARNING, this patch is for now an ugly patch :o( I am sorry ...
This patch brings 2 new classes, PolyLineLabelDecoration and PolylineLabelLocator. It also modify the PolyLineConnection's figure in order to add a new method allowing clients to add the polyline label decoration.
The PolylineLabelDecoration figure currently extends Label. Not sure this is the best solution. What do you think ? If this solution is retained we should take into account label's image, position etc .. and override all label's "coordinates computation" method.
Thus we could have a polyline label decoration answering to Mark requirements:
"Is this decoration able to line break the text in case that the line is not as long as the text? Can I positions the label right, center, left, above and beneath the line? Is the label rotatable? Because on an vertical line an arrow can point to the top, then i would read the text from the bottom. In the other case, if the arrow points to the bottom, I would read from above."
Created attachment 142152 stack trace
DeferredUpdateManager -> performValidation() this cycle has an error: for (int i = 0; i < invalidFigures.size(); i++) { fig = (IFigure) invalidFigures.get(i); invalidFigures.set(i, null); fig.validate(); } should be: for (int i = 0; i < invalidFigures.size(); i++) { fig = (IFigure) invalidFigures.get(i); fig.validate(); invalidFigures.set(i, null); } cause possible to get infinite loop. I get this loop. Look -> DeferredUpdateManager -> public synchronized void addInvalidFigure(IFigure f) { if (invalidFigures.contains(f)) return; queueWork(); invalidFigures.add(f); }
Bug 286630 - ScrollPane shows selection handles of selected objects even if object is not visible in viewport
Created attachment 144521 Screenshot of the selection error
Build ID: I20080617-2000
Steps To Reproduce:
- Create a scrollpane having a container figure having three child figures.
- resize the scrollpane within the ui so only two child figures are visible so that the vertical scrollbar appears
- select the first figure and scroll down the items via the scroll bar
- see the selection handles still being painted although figure is not visible
More information: The problem can be solved within the RelativeLocate#relocate method. This method is called whenever a relocation of a figure relative to a target figure is to be done. The reference figure is contained within a Viewport and may not be visible whereas the SelectionHandle figure resides on another layer and another viewport effectively being visible even if the figure is not. The relocate method calculates the new location of the SelectionHandle but should additionally check whether it is visible.
if a figure is added to a layer and its size is set before its location, the entire screen is forced to repaint.
-
when "set size" is performed it does a repaint--which DefferedUpdateManager remembers as a rect at 0,0,w,h
-
if the figure position is set next, another repaint is done--which DefferedUpdateManager OR's with the first rectangle such that now a rectangle from 0,0 to whatever the new location is which can potentially be on the other side of the screen
this can be fixed by having a "isLocationSet" flag in Figure-- unless a setBounds or setLocation has been executed this flag is false. if a setSize is done it should not do a repaint unless this flag is true
Bug 298976 - ArrayIndexOutOfBoundsException during deactivationFigure() of PolylineConnection with PolygonDecoration
I have no problem calling deactivationFigure() in AbstractConnectionEditPart if my figure (PolylineConnection) doesn't have a decoration.
As soon as I add a "decoration" to my figure, PolygonDecoration sourceDecoration = new PolygonDecoration(); ((PolylineConnection) connectionFigure).setSourceDecoration(sourceDecoration);
deactivationFigure() gets ArrayIndexOutOfBoundsException.
Here is the stack trace.
java.lang.ArrayIndexOutOfBoundsException: -1 at java.util.ArrayList.remove(Unknown Source) at org.eclipse.draw2d.graph.ShortestPathRouter.internalRemoveObstacle(ShortestPathRouter.java:379) at org.eclipse.draw2d.graph.ShortestPathRouter.removeObstacle(ShortestPathRouter.java:594) at org.eclipse.draw2d.ShortestPathConnectionRouter.removeChild(ShortestPathConnectionRouter.java:238) at org.eclipse.draw2d.ShortestPathConnectionRouter.unhookAll(ShortestPathConnectionRouter.java:114) at org.eclipse.draw2d.ShortestPathConnectionRouter.remove(ShortestPathConnectionRouter.java:226) at org.eclipse.draw2d.PolylineConnection.setConnectionRouter(PolylineConnection.java:229) at org.eclipse.draw2d.ConnectionLayer.remove(ConnectionLayer.java:75) at org.eclipse.gef.editparts.AbstractConnectionEditPart.deactivateFigure(AbstractConnectionEditPart.java:122)
Bug 310723 - FanRouter and ManhattanConnectionRouter need to be adopted to replacement of Ray with Vector.
FanRouter and ManhattanConnectionRouter are the only framework classes that make use of the now deprecated Ray class. They should be adopted to use the newly introduced Vector replacement class.
Fixed via https://github.com/eclipse-gef/gef-classic/pull/584
Build Identifier: 3.5.1.v20090813-1341
I've been trying to print GEF Figures and the text within the GEF figures are always printed out larger than they are actually displayed in the UI.
I tested this with example code off the internet and the same problem occurred. url for example code: http://demo.spars.info/j/frameset.cgi?compo_id=171393&mode=frameset&ref=3&method=137&MORPHO=1&location=1111111111111111111&LANG=1
just comment out the line: Label icon = new Label(new Image(null, PrintExample.class.getResourceAsStream("brazil.ico"))); and where icon was added to figure. for it to run.
Reproducible: Always
Build Identifier: 3.6.0.v20100429-2050-45-7w3121153903161
We use Ellipses and Rectangles that are connected with PolylineConnections. All figures are drawn a half pixel too high and a half pixel to wide left relative to the connection lines. As a result (a) the connections below end a half pixel before the figures, i.e., there is a gap and (b) our ellipse miss some parts to the top and to the left.
Unfortunately, I cannot adjust the positions for printing, because it is only a half pixel and the ellipse is drawn in its box (increasing the box does not help).
The GEF examples do not allow printing nor zooming so that I was not able to easily verify that this problem is a general Draw2D issue, but I'm pretty sure.
Reproducible: Always
Build Identifier: HEAD
We have a diagram where we use panning tool to pan on the diagram. Whilst developing this diagram, we have discovered the painting process is quite jumpy and flickering only if panning is done on both X and Y axises.
Looking at the code for FigureCanvas, there is an obvious optimization if scrollTo results in scrolling in only on X or Y direction.
With the patch we perceive a highly noticeable better performance when scroll is in arbitrary direction (panning).
Hope this improvement makes its way into gef sources.
Reproducible: Always
Steps to Reproduce:
- use the panning tool in examples
- pay attention to jumpy / flickering paint performance as user pans in both X and Y direction
- try the same with scroll bars (which scrolls only on one axis at a time)
- apply the patch and repeat 1,2,3.
Build Identifier: 20100617-1415
This is related to all events. I recently wrote a DeleteAction handling the DeleteCommand for a draw2d-based editor. After this the delete-event occured twice in our widget.
The org.eclipse.draw2d.SWTEventDispatcher-Listeners don't check the draw2d-event's isConsumed()-state. The all should copy it back to the origional swt-event.doit field before returning.
This bug report should better benamed as "Consuming events in draw2d have no effect on the origial swt-event"
Reproducible: Always
Steps to Reproduce:
import org.eclipse.draw2d.; import org.eclipse.swt.events.KeyEvent; import org.eclipse.swt.events.KeyListener; import org.eclipse.swt.layout.FillLayout; import org.eclipse.swt.widgets.;
public class FigureCanvaseTestApp {
public static void main(String[] args) { Shell shell = new Shell(); shell.setLayout(new FillLayout()); FigureCanvas canvas = new FigureCanvas(shell); canvas.getLightweightSystem().setEventDispatcher(new SWTEventDispatcher() {
// uncomment to fix for keyEvent
// /**
// * @see EventDispatcher#dispatchKeyPressed(org.eclipse.swt.events.KeyEvent)
// */
// @Override
// public void dispatchKeyPressed(org.eclipse.swt.events.KeyEvent e) {
// IFigure focusOwner = getFocusOwner();
// if (focusOwner != null) {
// org.eclipse.draw2d.KeyEvent event = new org.eclipse.draw2d.KeyEvent(this, focusOwner, e);
// focusOwner.handleKeyPressed(event);
// e.doit = !event.isConsumed();
// }
// }
//
// @Override
// public void dispatchKeyReleased(KeyEvent e) {
// IFigure focusOwner = getFocusOwner();
// if (focusOwner != null) {
// org.eclipse.draw2d.KeyEvent event = new org.eclipse.draw2d.KeyEvent(this, focusOwner, e);
// focusOwner.handleKeyReleased(event);
// e.doit = !event.isConsumed();
// }
// }
});
Figure rootFigure = new Figure();
rootFigure.setRequestFocusEnabled(true);
rootFigure.setOpaque(true);
rootFigure.setBackgroundColor(ColorConstants.blue);
rootFigure.addKeyListener(new org.eclipse.draw2d.KeyListener() {
@Override
public void keyPressed(org.eclipse.draw2d.KeyEvent ke) {
System.out.println("figure - keyPressed - isConsumed: " + ke.isConsumed());
ke.consume();
}
@Override
public void keyReleased(org.eclipse.draw2d.KeyEvent ke) {
}
});
canvas.setContents(rootFigure);
canvas.addKeyListener(new KeyListener() {
@Override
public void keyReleased(KeyEvent e) {
}
@Override
public void keyPressed(KeyEvent e) {
System.out.println("canvas - keyPressed - doit: " + e.doit);
}
});
shell.setBounds(10, 10, 600, 400);
shell.layout();
shell.setVisible(true);
canvas.setFocus();
rootFigure.requestFocus();
Display display = shell.getDisplay();
while (!shell.isDisposed()) {
if (!shell.getDisplay().readAndDispatch()) display.sleep();
}
} }
Build Identifier: M20100909-0800
Figure class used instead of IFigure interface in SWTEventDispatcher. Implemnting IFigure ,instead of extending Figure, causes ClassCastingException.
following is snippet from org.eclipse.draw2d.SWTEventDispatcher:
protected void setHoverSource(Figure figure, org.eclipse.swt.events.MouseEvent me) { ...}
protected void updateHoverSource(org.eclipse.swt.events.MouseEvent me) { /* * Derive source from figure under cursor. ... */ if (cursorTarget != null) { boolean sourceFound = false; Figure source = (Figure) cursorTarget; while (!sourceFound && source.getParent() != null) { if (source.getToolTip() != null) sourceFound = true; else source = (Figure) source.getParent(); } setHoverSource(source, me); } else { setHoverSource(null, me); } }
I couldn't find any reason to use Figure class in this code.
Reproducible: Always
Steps to Reproduce: nothing to reproduce
Created attachment 181809 image revealing the mentioned gap
This bug was observed in a Graphiti based diagram.
As of the discussion following http://www.eclipse.org/forums/index.php?t=msg&th=198956&start=0&S=75d2be8d91fb1185adf47d502a7bda94 Tim Kaiser from Graphiti could reproduce it and tracked it back to a problem in the underlying GEF/draw2d layer.
In attached figure the inner GA is a filled ellipse:
Ellipse inset = gaService.createEllipse(invisibleRectangle); inset.setForeground(manageColor(fill)); inset.setBackground(manageColor(fill)); inset.setLineWidth(LINE_WIDTH); gaService.setLocationAndSize(inset, 3size/4, 3size/4, size/2, size/2);
The rendering leaves a little gap of background color on the upper left part.
setting the ellipse filled inset.setFilled(true); doesn't change the behavior.
FlowLayout seems to mix up major and minor spacing. That is, while the javadoc states that the major spacing affects "the spacing in pixels to be used between children in the direction parallel to the layout's orientation", which is in my eyes also the intuitive meaning of the term "major spacing", the value set for the major spacing actually affects the spacing perpendicular to the layout orientation, and vice versa. You may easily reproduce this using the FlowLayoutExample snippet of the Draw2d examples.
It's a common misconception that SWT can only be used from a Display thread (even if this were true, on some platform you can construct more than one Display). The Display-thread limitation is true for SWT's Widgets, but the limitation does not apply to Images, GCs, Fonts, Colors, Patterns, Regions, Transforms, etc. Draw2d/GEF are being used on servers to generate images for webpages. They can also be used in rich client applications by background "worker" threads to generate thumbnails or other images. Today, clients must use workarounds to guarantee proper results. These workarounds include placing all calls to figure validation and painting inside a synchronized block. When handling multiple requests from clients, the server is effectively single-threaded.
FWIW, ColorConstants was changed in the past to allow the class to be loaded by a background thread.
There are only a few remaining places to patch that would allow draw2d to safely be used in multiple threads. Note that I'm not suggesting that instances of figures or anything else would be thread-safe. The changes proposed here are the minimum required so that completely unrelated instances of figure, etc. can be validated and then painted onto images.
- FigureUtilities changes:
protected static GC getGC() { if (gc == null) { gc = new GC(new Image(null, 1, 1)); appliedFont = gc.getFont(); } return gc; }
Instead of creating a Shell, which must happen the first time on a Display thread, use an Image instead. Images can be created on any thread.
getFontMetrics, getStringDimension, and getTextDimension all need to be made synchronized to guarantee exclusive access to the GC singleton.
- Delete all occurrences of static Point and Rectangle instances (except for the ones which are not expected to ever change). If they are currently API, @deprecate. Fix all broken code to just use new instances.
- AbstractBorder#tempRect (becomes @deprecated)
- Figure#PRIVATE_RECT
- Figure#PRIVATE_POINT
- AbstractRouter#START
- AbstractRouter#END
- Rectangle#SINGLETON (becomes @deprecated)
- Point#SINGLETON (becomes @deprecated)
- Dimension#SINGLETON (becomes @deprecated)
- [optional] If creating new geometry instances is really still a performance concern on modern JVMs, the biggest offender is probably in Figure#paintClientArea. To avoid creating a new Rectangle there, just add a new method: Graphics#clipRect(int,int,int,int).
As reported in bug #135352, animation does not work on GTK in case compiz extension is enabled (opening this one to keep track of the GTK/Compiz misbehavior, while bug #135352 is related to Mac OS X).
graph.setBackgroundImage(myImage); does not work properly. The image DOES get applied, but gets overwritten immediately because some built-in mechanism is painting over it with the background color right away. Try resizing the window (or hiding/showing it) and you should be able to see the background image for a microsecond or two before the PaintListener covers it over with the background color. A work-around is to use graph().getLightweightSystem().getRootFigure().setOpaque(false); before the code given up top. Mark
Build Identifier: 20110615-0604
Bug #253670 describes a problem with SWT GC where rotation causes drawXxx and fillXxx to be misaligned at certain angles (45, 135, 225, 315). In SWT you can work around this by setting the GC data state mask to DRAW_OFFSET.
This does not work in Draw2D, as you don't have access to the GC, only to the Draw2D SWTGraphics. Draw2D should implement support for this workaround.
Reproducible: Always
Steps to Reproduce:
- Create a Shape that fills and draws a rotated rectangle, and set the rotation angle to 45°.
Build Identifier: 20110301-1815
To break text into lines the canBreakAfter method is used. This method now checks for whitespace and dashes.
In some contexts, this is not desirable, for instance when building a WYSIWYG (X)HTML editor. In browsers, words are not broken off at dashes.
It would be great if this could be configured with a parameter, for instance an extra wrapping option in ParagraphTextLayout.
Reproducible: Always
Steps to Reproduce:
- Create a textFlow with some text in it with words with dashes.
- Set the size of the container to cause line-breaking.
- Words are broken of at the dashes.
Bug 363562 - Freeform bounds and scroll bars not correct calculated if figure has negative coordinates
Build Identifier: org.eclipse.draw2d_3.6.2.v20110128-0100.jar
I have an application which uses the FreeformViewport via ScalableFreeformRootEditPart. If a figure is shown which has mostly negative coordinates an empty space is shown below or beside the figure. Also the scroll bars are incorrect displayed: even if the figure has the same size as the view port the scroll bars shows addition space and therefore allows scrolling. I investigate the problem and found the possible cause: The new bounds might be calculated wrong in FreeformViewport.readjustScrollBars(). The bounds from the FreeformFigure and the client area are combined by an union operator reference the point 0/0 and the client's width and height, but the client's x/y should be used as reference. I could fix the problem by changing the union with "bounds.union(clientArea);" I attached a drawing which visualize the problem.
Reproducible: Always
Steps to Reproduce:
- Create an editor with a SclableFreeformRootEditPart
- Place a figure with negative coordinates on the layer
- Zoom to fit the figure on the page
- check the scroll bars and its extend
Build Identifier: M20080911-1700
We have an editor built using the GEF framework and recently we ran into an issue when dealing with multiple display monitors. Take the following setup: 2 monitors next to eachother, with our application running maximized on the left monitor. When hovering a figure close to the right edge, a tooltip pops up but if it is long enough, it will extend onto the second display, making it hard to read the message. The tooltip's location is calculated using the ToolTipHelper class which doesn't seem to take multiple monitors with display extension into account. The debugger showed that the clientArea was in fact 3840x1080, which corresponds to both monitors.
It seems impossible to use a custom ToolTipHelper without hacking too much into the Draw2D framework.
Reproducible: Always
Fixed via https://github.com/eclipse-gef/gef-classic/pull/726
Bug 371091 - FlowFigure#add(IFigure child, Object constraint, int index) can causes NPE because FlowContext is set too late.
In FlowFigure:
public void add(IFigure child, Object constraint, int index) {
super.add(child, constraint, index);
// If this layout manager is a FlowContext, then the child must be a
// FlowFigure
if (getLayoutManager() instanceof FlowContext)
((FlowFigure) child)
.setFlowContext((FlowContext) getLayoutManager());
revalidateBidi(this);
}
Problem is on first line: "super.add(child, constraint, index);" causes (in Figure#add) a call to #revalidate(), which signals the figure as invalid to the UpdateManager, while the child Figure doesn't have its FlowContext set yet (and so will cause a NPE if UpdateManager tries to validate it right away).
Setting the FlowContext of child figure before calling super.add does fix the problem.
Note: For some reasons specific to my project, I do not use the "standard" DeferredUpdateManager that queues validation work until a PAINT event occurs but a more "synchronous" one that performs validation as soon as invalid figures are signaled.
public synchronized void addInvalidFigure(final IFigure f) {
// Note the invalid figure...
this.invalidFigures.add(f);
// ...and perform update and validation right away!
Display display = Display.getCurrent();
if (display == null) {
throw new SWTException(SWT.ERROR_THREAD_INVALID_ACCESS);
}
display.syncExec(new UpdateRequest());
}
This is why the problem occurs every time for me. But the problem might as well happen with the regular DeferredUpdateManager, depending on multithread weaving I guess. More importantly: FlowFigure implementation should probably not depend on some assertion about the UpdateManager's implementation, should it?
Build Identifier: org.eclipse.draw2d_3.6.0.v20100525-1225.jar
We are using the GEF palette and we have an incident where a palette tooltip is wrapping in an unnatural way in Chinese. The text wrapping results with only a period on the second line. I don't see this happening in English, so I think it is an issue specific to the locale. I will upload a screen cap of the issue.
Reproducible: Always
Build Identifier: 3.6.2.v20110128-0100
We have a org.eclipse.gmf.runtime.draw2d.ui.figures.WrappingLabel which uses a TextFlow. This label is updated from a non-UI Thread via Display.asyncExec(). Normally this works fine, i.e. setting the text makes the label invalid and forces correct calculation of the text flow and revalidation. However, there are situations where the Thumbnail (visible in an Outline) update code calls paint() and forces the TextFlow to paint itself even though the label/flow is currently invalid. Thus we can run into a StringIndexOutOfBoundsException because the new text has been set, but the flow has not be recalculated yet.
org.eclipse.swt.SWTException: Failed to execute runnable (java.lang.StringIndexOutOfBoundsException: String index out of range: 5) at org.eclipse.swt.SWT.error(SWT.java:4083) at org.eclipse.swt.SWT.error(SWT.java:3998) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:137) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3593) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3286) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2640) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2604) at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2438) at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:671) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:664) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149) at ch.belimo.bd.application.Application.start(Application.java:149) 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:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:620) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:575) at org.eclipse.equinox.launcher.Main.run(Main.java:1408) at org.eclipse.equinox.launcher.Main.main(Main.java:1384) Caused by: java.lang.StringIndexOutOfBoundsException: String index out of range: 5 at java.lang.String.substring(String.java:1934) at org.eclipse.draw2d.text.TextFlow.getBidiSubstring(TextFlow.java:223) at org.eclipse.gmf.runtime.draw2d.ui.text.TextFlowEx.paintFigure(TextFlowEx.java:157) at org.eclipse.draw2d.Figure.paint(Figure.java:1115) at org.eclipse.draw2d.Figure.paintChildren(Figure.java:1167) at org.eclipse.draw2d.Figure.paintClientArea(Figure.java:1197) at org.eclipse.draw2d.Figure.paint(Figure.java:1117) at org.eclipse.draw2d.Figure.paintChildren(Figure.java:1167) at org.eclipse.draw2d.Figure.paintClientArea(Figure.java:1206) at org.eclipse.gmf.runtime.draw2d.ui.figures.WrappingLabel.paintClientArea(WrappingLabel.java:1104) at org.eclipse.draw2d.Figure.paint(Figure.java:1117) at org.eclipse.draw2d.Figure.paintChildren(Figure.java:1167) at org.eclipse.draw2d.Figure.paintClientArea(Figure.java:1202) at org.eclipse.draw2d.Figure.paint(Figure.java:1117) at org.eclipse.draw2d.Figure.paintChildren(Figure.java:1167) at org.eclipse.draw2d.Figure.paintClientArea(Figure.java:1202) at org.eclipse.draw2d.Figure.paint(Figure.java:1117) at org.eclipse.draw2d.Figure.paintChildren(Figure.java:1167) at org.eclipse.gmf.runtime.diagram.ui.internal.figures.BorderItemContainerFigure.paintClientArea(BorderItemContainerFigure.java:85) at org.eclipse.draw2d.Figure.paint(Figure.java:1117) at org.eclipse.draw2d.Figure.paintChildren(Figure.java:1167) at org.eclipse.draw2d.Figure.paintClientArea(Figure.java:1202) at org.eclipse.draw2d.Figure.paint(Figure.java:1117) at org.eclipse.draw2d.Figure.paintChildren(Figure.java:1167) at org.eclipse.draw2d.Figure.paintClientArea(Figure.java:1202) at org.eclipse.draw2d.Figure.paint(Figure.java:1117) at org.eclipse.draw2d.Figure.paintChildren(Figure.java:1167) at org.eclipse.draw2d.Figure.paintClientArea(Figure.java:1202) at org.eclipse.draw2d.Figure.paint(Figure.java:1117) at org.eclipse.draw2d.Figure.paintChildren(Figure.java:1167) at org.eclipse.draw2d.Figure.paintClientArea(Figure.java:1202) at org.eclipse.draw2d.Figure.paint(Figure.java:1117) at org.eclipse.draw2d.Figure.paintChildren(Figure.java:1167) at org.eclipse.draw2d.Figure.paintClientArea(Figure.java:1197) at org.eclipse.draw2d.Viewport.paintClientArea(Viewport.java:160) at org.eclipse.draw2d.Figure.paint(Figure.java:1117) at org.eclipse.draw2d.Figure.paintChildren(Figure.java:1167) at org.eclipse.draw2d.Figure.paintClientArea(Figure.java:1206) at org.eclipse.draw2d.Figure.paint(Figure.java:1117) at org.eclipse.draw2d.Figure.paintChildren(Figure.java:1167) at org.eclipse.draw2d.Figure.paintClientArea(Figure.java:1202) at org.eclipse.draw2d.Figure.paint(Figure.java:1117) at org.eclipse.draw2d.Figure.paintChildren(Figure.java:1167) at org.eclipse.draw2d.Figure.paintClientArea(Figure.java:1202) at org.eclipse.draw2d.Figure.paint(Figure.java:1117) at org.eclipse.draw2d.Figure.paintChildren(Figure.java:1167) at org.eclipse.draw2d.Figure.paintClientArea(Figure.java:1202) at org.eclipse.draw2d.Figure.paint(Figure.java:1117) at org.eclipse.draw2d.Figure.paintChildren(Figure.java:1167) at org.eclipse.draw2d.Figure.paintClientArea(Figure.java:1202) at org.eclipse.draw2d.Figure.paint(Figure.java:1117) at org.eclipse.draw2d.Figure.paintChildren(Figure.java:1167) at org.eclipse.draw2d.Figure.paintClientArea(Figure.java:1202) at org.eclipse.draw2d.Figure.paint(Figure.java:1117) at org.eclipse.draw2d.Figure.paintChildren(Figure.java:1167) at org.eclipse.draw2d.Figure.paintClientArea(Figure.java:1197) at org.eclipse.draw2d.Viewport.paintClientArea(Viewport.java:160) at org.eclipse.draw2d.Figure.paint(Figure.java:1117) at org.eclipse.draw2d.Figure.paintChildren(Figure.java:1167) at org.eclipse.draw2d.Figure.paintClientArea(Figure.java:1206) at org.eclipse.draw2d.Figure.paint(Figure.java:1117) at org.eclipse.draw2d.Figure.paintChildren(Figure.java:1167) at org.eclipse.draw2d.Figure.paintClientArea(Figure.java:1202) at org.eclipse.draw2d.Figure.paint(Figure.java:1117) at org.eclipse.draw2d.Figure.paintChildren(Figure.java:1167) at org.eclipse.draw2d.Figure.paintClientArea(Figure.java:1202) at org.eclipse.draw2d.Figure.paint(Figure.java:1117) at org.eclipse.draw2d.Figure.paintChildren(Figure.java:1167) at org.eclipse.draw2d.Figure.paintClientArea(Figure.java:1202) at org.eclipse.draw2d.Figure.paint(Figure.java:1117) at org.eclipse.draw2d.Figure.paintChildren(Figure.java:1167) at org.eclipse.draw2d.Figure.paintClientArea(Figure.java:1202) at org.eclipse.draw2d.Figure.paint(Figure.java:1117) at org.eclipse.draw2d.Figure.paintChildren(Figure.java:1167) at org.eclipse.draw2d.Figure.paintClientArea(Figure.java:1202) at org.eclipse.draw2d.Figure.paint(Figure.java:1117) at org.eclipse.draw2d.Figure.paintChildren(Figure.java:1167) at org.eclipse.draw2d.Figure.paintClientArea(Figure.java:1202) at org.eclipse.draw2d.Figure.paint(Figure.java:1117) at org.eclipse.draw2d.Figure.paintChildren(Figure.java:1167) at org.eclipse.draw2d.Figure.paintClientArea(Figure.java:1197) at org.eclipse.draw2d.Viewport.paintClientArea(Viewport.java:160) at org.eclipse.draw2d.Figure.paint(Figure.java:1117) at org.eclipse.draw2d.Figure.paintChildren(Figure.java:1167) at org.eclipse.draw2d.Figure.paintClientArea(Figure.java:1206) at org.eclipse.draw2d.Figure.paint(Figure.java:1117) at org.eclipse.draw2d.Figure.paintChildren(Figure.java:1167) at org.eclipse.draw2d.Figure.paintClientArea(Figure.java:1202) at org.eclipse.draw2d.Figure.paint(Figure.java:1117) at org.eclipse.draw2d.Figure.paintChildren(Figure.java:1167) at org.eclipse.draw2d.Figure.paintClientArea(Figure.java:1202) at org.eclipse.draw2d.Figure.paint(Figure.java:1117) at org.eclipse.draw2d.Figure.paintChildren(Figure.java:1167) at org.eclipse.draw2d.Figure.paintClientArea(Figure.java:1202) at org.eclipse.draw2d.Figure.paint(Figure.java:1117) at org.eclipse.draw2d.Figure.paintChildren(Figure.java:1167) at org.eclipse.draw2d.Figure.paintClientArea(Figure.java:1202) at org.eclipse.draw2d.Figure.paint(Figure.java:1117) at org.eclipse.draw2d.Figure.paintChildren(Figure.java:1167) at org.eclipse.draw2d.Figure.paintClientArea(Figure.java:1202) at org.eclipse.draw2d.Figure.paint(Figure.java:1117) at org.eclipse.draw2d.Figure.paintChildren(Figure.java:1167) at org.eclipse.draw2d.Figure.paintClientArea(Figure.java:1202) at org.eclipse.draw2d.Figure.paint(Figure.java:1117) at org.eclipse.draw2d.Figure.paintChildren(Figure.java:1167) at org.eclipse.draw2d.Figure.paintClientArea(Figure.java:1197) at org.eclipse.draw2d.Viewport.paintClientArea(Viewport.java:160) at org.eclipse.draw2d.Figure.paint(Figure.java:1117) at org.eclipse.draw2d.Figure.paintChildren(Figure.java:1167) at org.eclipse.draw2d.Figure.paintClientArea(Figure.java:1206) at org.eclipse.draw2d.Figure.paint(Figure.java:1117) at org.eclipse.draw2d.Figure.paintChildren(Figure.java:1167) at org.eclipse.draw2d.Figure.paintClientArea(Figure.java:1202) at org.eclipse.draw2d.Figure.paint(Figure.java:1117) at org.eclipse.draw2d.Figure.paintChildren(Figure.java:1167) at org.eclipse.draw2d.Figure.paintClientArea(Figure.java:1202) at org.eclipse.draw2d.Figure.paint(Figure.java:1117) at org.eclipse.draw2d.Figure.paintChildren(Figure.java:1167) at org.eclipse.draw2d.Figure.paintClientArea(Figure.java:1202) at org.eclipse.draw2d.Figure.paint(Figure.java:1117) at org.eclipse.draw2d.Figure.paintChildren(Figure.java:1167) at org.eclipse.draw2d.Figure.paintClientArea(Figure.java:1202) at org.eclipse.draw2d.Figure.paint(Figure.java:1117) at org.eclipse.draw2d.Figure.paintChildren(Figure.java:1167) at org.eclipse.draw2d.Figure.paintClientArea(Figure.java:1202) at org.eclipse.draw2d.Figure.paint(Figure.java:1117) at org.eclipse.draw2d.Figure.paintChildren(Figure.java:1167) at org.eclipse.draw2d.Figure.paintClientArea(Figure.java:1202) at org.eclipse.draw2d.Figure.paint(Figure.java:1117) at org.eclipse.draw2d.Figure.paintChildren(Figure.java:1167) at org.eclipse.draw2d.Figure.paintClientArea(Figure.java:1202) at org.eclipse.draw2d.Figure.paint(Figure.java:1117) at org.eclipse.draw2d.Figure.paintChildren(Figure.java:1167) at org.eclipse.draw2d.Figure.paintClientArea(Figure.java:1202) at org.eclipse.draw2d.ScalableFreeformLayeredPane.paintClientArea(ScalableFreeformLayeredPane.java:60) at org.eclipse.gmf.runtime.draw2d.ui.internal.graphics.ScalableFreeformLayeredPane.paintClientArea(ScalableFreeformLayeredPane.java:82) at org.eclipse.draw2d.Figure.paint(Figure.java:1117) at org.eclipse.draw2d.parts.Thumbnail$ThumbnailUpdater.run(Thumbnail.java:166) at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:134) ... 23 more
Reproducible: Sometimes
Steps to Reproduce:
- Create a graphical editor with an outline
- Update the text of a WrappingLabel from a non-UI thread
Build Identifier: Version: Indigo Service Release 2 Build id: 20120216-1857
When using two connections between two objects and deleting the "straight" one, the other one does not get revalidated.
When the other connection is added again, both are drawn bend and overlay each other.
This image should illustrate the issue: http://imageshack.us/photo/my-images/856/routerb.jpg
The router uses this part to get check the other connections:
int index = connections.remove(connectionKey, conn); for (int i = index + 1; i < connectionList.size(); i++) ((Connection) connectionList.get(i)).revalidate();
Because i is 1 (because the index is 0) and the size of the list is also 1, the loop is never entered.
When the connection is added again, the router assumes, that the existing one is routed straight and therefor also bends the new connection.
Reproducible: Always
Steps to Reproduce: 1.Use a AutomaticRouter (e.g. FanRouter) for the editor/connection layer 2.add two objects and connect them with two connections 3.delete the straight connection 4.add a new connection between the two objects
Build Identifier: M20100211-1343
When I layout a graph using CompoundDirectedGraphLayout, some nodes overlap. This happens when nodes (org.eclipse.draw2d.graph.Node) have no parent. If I create these nodes (org.eclipse.draw2d.graph.Node) with common parent (org.eclipse.draw2d.graph.Subgraph), it seems to work fine.
The problem can be reproduced using GEF flow example with following change in StructuredActivityPart class:
public void contributeNodesToGraph(CompoundDirectedGraph graph, Subgraph s, Map map) { GraphAnimation.recordInitialState(getContentPane()); // Subgraph me = new Subgraph(this, s); // me.rowOrder = getActivity().getSortIndex(); // me.outgoingOffset = 5; // me.incomingOffset = 5; // IFigure fig = getFigure(); // if (fig instanceof SubgraphFigure) { // me.width = fig.getPreferredSize(me.width, me.height).width; // int tagHeight = ((SubgraphFigure)fig).getHeader().getPreferredSize().height; // me.insets.top = tagHeight; // me.insets.left = 0; // me.insets.bottom = tagHeight; // } // me.innerPadding = INNER_PADDING; // me.setPadding(PADDING); // map.put(this, me); // graph.nodes.add(me); for (int i = 0; i < getChildren().size(); i++) { ActivityPart activity = (ActivityPart)getChildren().get(i); activity.contributeNodesToGraph(graph, null/me/, map); } }
Notes:
- The attached graph is the smallest graph where it happens to me.
- The order the nodes are added to graph using graph.nodes.add() is important. Some orders do not cause this problem. The problem can be reproduced when nodes are sorted alphabetically (a1, b1, b2, ...).
- I think the problem is in org.eclipse.draw2d.graph.HorizontalPlacement.balanceClusters() method. If this method is not called, then the nodes do not overlap (no matter the nodes have common parent or not).
Reproducible: Always
Steps to Reproduce:
- Run the example plugin with change mentioned above.
- Open attached flow file.
- Nodes overlap.
Build Identifier: Version: Indigo Service Release 2 Build id: 20120216-1857
The helper functions lighter operate in the rgb color space and there the each element is transformed independent of the others. If you have pure colors (e.g., red with rgb<255,0,0>) than the transformation results in the same color. The correct way would be to use the HSL color space. I did some tests with it and than the problem is gone.
Furthermore this affects also other helper functions in the FigureUtilities like paintEtchedBorder.
Reproducible: Always
A Label showing numbers should paint its text right aligned, but the position of the text is computed with regard of its preferred size:
Dimension offset = getSize().getDifference(getPreferredSize());
When using GridLayout and GridData, the GridData sets the Figure's preferred size directly:
Dimension size = figure.getPreferredSize(widthHint, heightHint); if (widthHint != -1) size.width = widthHint; if (heightHint != -1) size.height = heightHint;
The problem is, when you use a hint:
Label label = new Label("0"); label.setLabelAlignment(PositionConstants.RIGHT);
GridData data = new GridData(); data.horizontalAlignment = SWT.FILL: data.widthHint = 100;
container.add(label, data);
Then is the text painted on the left side instead of right size.
package com.dnastar.common.ui.draw2d;
import java.beans.PropertyChangeEvent; import java.beans.PropertyChangeListener;
import org.eclipse.draw2d.GridData; import org.eclipse.draw2d.GridLayout; import org.eclipse.draw2d.LightweightSystem; import org.eclipse.draw2d.RectangleFigure; import org.eclipse.draw2d.ScrollBar; import org.eclipse.swt.SWT; import org.eclipse.swt.layout.FillLayout; import org.eclipse.swt.widgets.Canvas; import org.eclipse.swt.widgets.Composite; import org.eclipse.swt.widgets.Display; import org.eclipse.swt.widgets.Shell;
public class Bug extends Composite { private static final int VALUE = 0; private static final int EXTENT = 1; private static final int MIN = 0; private static final int MAX = 100;
private ScrollBar m_scroll;
public Bug(Composite parent, int style) {
super(parent, style);
setLayout(new FillLayout());
Canvas canvas = new Canvas(this, SWT.NONE);
final LightweightSystem m_lws = new LightweightSystem();
m_lws.setControl(canvas);
final RectangleFigure top = new RectangleFigure();
top.setLayoutManager(new GridLayout(2, false));
m_lws.setContents(top);
m_scroll = new ScrollBar();
m_scroll.setHorizontal(true);
m_scroll.setMaximum(MAX);
m_scroll.setMinimum(MIN);
m_scroll.setPageIncrement(1);
m_scroll.setExtent(EXTENT);
m_scroll.setValue(VALUE);
top.add(m_scroll);
top.setConstraint(m_scroll, new GridData(SWT.FILL, SWT.FILL, true, false));
m_scroll.getRangeModel().addPropertyChangeListener(new PropertyChangeListener() {
@Override
public void propertyChange(PropertyChangeEvent arg0) {
m_scroll.invalidate();
m_lws.getUpdateManager().performUpdate();
}
});
}
public static void main(String[] args) {
Display display = new Display ();
Shell shell = new Shell (display);
shell.setLayout (new FillLayout ());
new Bug(shell, SWT.NONE);
shell.pack();
shell.open ();
while (!shell.isDisposed ()) {
if (!display.readAndDispatch ()) display.sleep ();
}
display.dispose ();
}
}
Hi,
I would like to know why is the draw2d so inaccurate when zooming is in use. I have added two screenshots with 100%(good.png) and 300%(bad.png) zoom. You can see the gaps between cells.
Created attachment 224571 Patch
Using a ConnectionEndpointLocator to locate labels on connections. If figure is in a parent figure where the parent figure returns true for
Fix for org.eclipse.draw2d.ConnectionEndpointLocator Problem: when a Figure is inside another Figure which returns true for useLocalCoordinates() (uses local co-ordinate system) then the connection's label locator is screwed if set to source and figure is on the right, or set to target and the figure is on the left.
org.eclipse.swt.SWTException: Graphic is disposed at org.eclipse.swt.SWT.error(SWT.java:4282) at org.eclipse.swt.SWT.error(SWT.java:4197) at org.eclipse.swt.SWT.error(SWT.java:4168) at org.eclipse.swt.graphics.GC.getAdvanced(GC.java:2287) at org.eclipse.draw2d.SWTGraphics.restoreState(SWTGraphics.java:928) at org.eclipse.draw2d.SWTGraphics.popState(SWTGraphics.java:828) at org.eclipse.gmf.runtime.draw2d.ui.internal.graphics.ScaledGraphics.popState(ScaledGraphics.java:646) at org.eclipse.gmf.runtime.draw2d.ui.internal.graphics.ScaledGraphics.dispose(ScaledGraphics.java:271) at org.eclipse.gmf.runtime.draw2d.ui.internal.parts.ThumbnailEx$ThumbnailUpdater.stop(ThumbnailEx.java:284) at org.eclipse.gmf.runtime.draw2d.ui.internal.parts.ThumbnailEx$ThumbnailUpdater.deactivate(ThumbnailEx.java:65) at org.eclipse.gmf.runtime.draw2d.ui.internal.parts.ThumbnailEx.deactivate(ThumbnailEx.java:344) at org.eclipse.gmf.runtime.draw2d.ui.internal.parts.ScrollableThumbnailEx.deactivate(ScrollableThumbnailEx.java:207) at org.eclipse.gmf.runtime.diagram.ui.parts.DiagramEditor$DiagramOutlinePage.dispose(DiagramEditor.java:276) at org.eclipse.ui.views.contentoutline.ContentOutline.doDestroyPage(ContentOutline.java:149) at org.eclipse.ui.part.PageBookView.removePage(PageBookView.java:857) at org.eclipse.ui.part.PageBookView.partClosed(PageBookView.java:784) at org.eclipse.ui.part.PageBookView$4.partClosed(PageBookView.java:1022) at org.eclipse.ui.internal.PartListenerList2$3.run(PartListenerList2.java:100) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.core.runtime.Platform.run(Platform.java:888) at org.eclipse.ui.internal.PartListenerList2.fireEvent(PartListenerList2.java:55) at org.eclipse.ui.internal.PartListenerList2.firePartClosed(PartListenerList2.java:98) at org.eclipse.ui.internal.PartService.firePartClosed(PartService.java:227) at org.eclipse.ui.internal.WorkbenchPagePartList.firePartClosed(WorkbenchPagePartList.java:39) at org.eclipse.ui.internal.PartList.partClosed(PartList.java:274) at org.eclipse.ui.internal.PartList.removePart(PartList.java:186) at org.eclipse.ui.internal.WorkbenchPage.disposePart(WorkbenchPage.java:1796) at org.eclipse.ui.internal.WorkbenchPage.handleDeferredEvents(WorkbenchPage.java:1501) at org.eclipse.ui.internal.WorkbenchPage.deferUpdates(WorkbenchPage.java:1485) at org.eclipse.ui.internal.WorkbenchPage.closeEditors(WorkbenchPage.java:1459) at org.eclipse.ui.internal.WorkbenchPage.closeEditor(WorkbenchPage.java:1514) at org.eclipse.ui.internal.EditorPane.doHide(EditorPane.java:61) at org.eclipse.ui.internal.PartStack.close(PartStack.java:537) at org.eclipse.ui.internal.EditorStack.close(EditorStack.java:206) at org.eclipse.ui.internal.PartStack$1.close(PartStack.java:120) at org.eclipse.ui.internal.presentations.util.TabbedStackPresentation$1.handleEvent(TabbedStackPresentation.java:83) at org.eclipse.ui.internal.presentations.util.AbstractTabFolder.fireEvent(AbstractTabFolder.java:269) at org.eclipse.ui.internal.presentations.util.AbstractTabFolder.fireEvent(AbstractTabFolder.java:278) at org.eclipse.ui.internal.presentations.defaultpresentation.DefaultTabFolder.access$1(DefaultTabFolder.java:1) at org.eclipse.ui.internal.presentations.defaultpresentation.DefaultTabFolder$1.closeButtonPressed(DefaultTabFolder.java:71) at org.eclipse.ui.internal.presentations.PaneFolder.notifyCloseListeners(PaneFolder.java:631) at org.eclipse.ui.internal.presentations.PaneFolder$3.close(PaneFolder.java:206) at org.eclipse.swt.custom.CTabFolder.onMouse(CTabFolder.java:1599) at org.eclipse.swt.custom.CTabFolder$1.handleEvent(CTabFolder.java:261) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84) at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4128) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1457) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1480) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1465) at org.eclipse.swt.widgets.Widget.notifyListeners(Widget.java:1270) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3974) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3613) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2701) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2665) at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2499) at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:679) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:668) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:123) 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:344) 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:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:622) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:577) at org.eclipse.equinox.launcher.Main.run(Main.java:1410)
Created attachment 235192 Screenshot
The attached example is one the GEF Examples with the only difference that the 2 figures have tooltips. Steps to reproduce:
- start the plugin and open the shape editor
- create a figure and open its tooltip
- detach the editor
- open the tooltip a the figure again
Sometimes it does not happen at the first try.
According to SWT FAQ, Advanced Graphics is supported by SWT in the following cases:
- SWT for Windows uses GDI+ for advanced graphics, which is installed on Windows XP and newer. Windows 2000 users can download and install a Microsoft package containing GDI+.
- SWT for GTK+ and Motif use Cairo for advanced graphics, which is installed on systems with GTK+ 2.8 or newer (for example RHEL 5).
- SWT for OS X uses Quartz for advanced graphics, which is installed on all supported OS X versions.
It seems this holds for all Luna supported platforms (http://www.eclipse.org/projects/project-plan.php?planurl=eclipse/development/plans/eclipse_project_plan_4_4.xml#target_environments).
As such, there does not seem to be need for an explicit ScaledGraphics anymore, as SWTGraphics could instead be used. We should thus deprecate ScaledGraphics and replace its usages with direct scaling of the underlying SWTGraphics.
Created attachment 246771 Dark background in Logic example editor
Eclipse Luna comes with a dark theme. When this dark theme is used editors based on GEF automatically get a dark background (see attached screenshot). I think this behavior is incorrect and the background should stay white. Otherwise the editor becomes close to useless.
The following incident was reported via the automated error reporting:
code: 0
plugin: org.eclipse.ui_3.107.0.v20140911-1616
message: Unhandled event loop exception
fingerprint: f8a6fc1e
exception class: java.lang.NullPointerException
exception message: -
number of children: 0
java.lang.NullPointerException: null
at org.eclipse.draw2d.SWTEventDispatcher.dispatchMousePressed(SWTEventDispatcher.java:243)
at org.eclipse.gef.ui.parts.DomainEventDispatcher.dispatchMousePressed(DomainEventDispatcher.java:340)
at org.eclipse.draw2d.LightweightSystem$EventHandler.mouseDown(LightweightSystem.java:523)
at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:192)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4464)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1388)
at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3803)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3413)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1151)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:337)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1032)
at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:148)
at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:637)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:337)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:580)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:150)
at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:141)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:380)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:235)
at sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-2)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:648)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:603)
at org.eclipse.equinox.launcher.Main.run(Main.java:1465)
General Information:
reported-by: emflef
anonymous-id: f837034f-4728-38f6-9027-549b12cb678d
eclipse-build-id: 4.5.0.I20140918-0330
eclipse-product: org.eclipse.epp.package.modeling.product
operating system: Linux 3.14.0 (x86) - gtk
jre-version: 1.7.0_67-b01
The following plug-ins were present on the execution stack (*): 1. org.eclipse.core.databinding.observable_1.4.1.v20140910-2107 2. org.eclipse.core.databinding_1.4.100.v20140910-2107 3. org.eclipse.core.runtime_3.10.0.v20140724-1132 4. org.eclipse.draw2d_3.10.0.201409290206 5. org.eclipse.e4.ui.workbench_1.2.0.v20140905-1352 6. org.eclipse.e4.ui.workbench.swt_0.12.100.v20140908-1525 7. org.eclipse.equinox.app_1.3.200.v20130910-1609 8. org.eclipse.equinox.launcher_1.3.0.v20140415-2008 9. org.eclipse.gef_3.10.0.201409290206 10. org.eclipse.swt_3.104.0.v20140916-1012 11. org.eclipse.ui_3.107.0.v20140911-1616 12. org.eclipse.ui.ide.application_1.0.600.v20140909-1818 13. org.eclipse.ui.ide_3.10.100.v20140905-0917
Please note that:
- Messages, stacktraces, and nested status objects may be shortened.
- Bug fields like status, resolution, and whiteboard are sent back to reporters.
- The list of present bundles and their respective versions was calculated by package naming heuristics. This may or may not reflect reality.
Other Resources:
- Report: https://dev.eclipse.org/recommenders/committers/confess/#/problems/54c4eeffbee810030da065af
- Manual: https://dev.eclipse.org/recommenders/community/confess/#/guide
Thank you for your assistance. Your friendly error-reports-inbox.
The following incident was reported via the automated error reporting:
code: 0
plugin: org.eclipse.ui_3.107.0.v20140911-1616
message: Unhandled event loop exception
fingerprint: 1a4aa00c
exception class: org.eclipse.swt.SWTException
exception message: Failed to execute runnable (org.eclipse.swt.SWTException: Widget is disposed)
number of children: 0
org.eclipse.swt.SWTException: Failed to execute runnable (org.eclipse.swt.SWTException: Widget is disposed)
at org.eclipse.swt.SWT.error(SWT.java:4441)
at org.eclipse.swt.SWT.error(SWT.java:4356)
at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:139)
at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3983)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3660)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1151)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:337)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1032)
at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:148)
at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:637)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:337)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:580)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:150)
at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:141)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:380)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:235)
at sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-2)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:648)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:603)
at org.eclipse.equinox.launcher.Main.run(Main.java:1465)
caused by: org.eclipse.swt.SWTException: Widget is disposed at org.eclipse.swt.SWT.error(SWT.java:4441) at org.eclipse.swt.SWT.error(SWT.java:4356) at org.eclipse.swt.SWT.error(SWT.java:4327) at org.eclipse.swt.widgets.Widget.error(Widget.java:783) at org.eclipse.swt.widgets.Widget.checkWidget(Widget.java:573) at org.eclipse.swt.widgets.Scrollable.getVerticalBar(Scrollable.java:266) at org.eclipse.draw2d.FigureCanvas$2.propertyChange(FigureCanvas.java:102) at java.beans.PropertyChangeSupport.fire(PropertyChangeSupport.java:335) at java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:327) at java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:263) at java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:283) at org.eclipse.draw2d.DefaultRangeModel.firePropertyChange(DefaultRangeModel.java:63) at org.eclipse.draw2d.DefaultRangeModel.setAll(DefaultRangeModel.java:122) at org.eclipse.draw2d.FreeformViewport.readjustScrollBars(FreeformViewport.java:74) at org.eclipse.draw2d.Viewport.validate(Viewport.java:381) at org.eclipse.draw2d.Figure.validate(Figure.java:1898) at org.eclipse.draw2d.DeferredUpdateManager.performValidation(DeferredUpdateManager.java:221) at org.eclipse.draw2d.DeferredUpdateManager.performUpdate(DeferredUpdateManager.java:193) at org.eclipse.draw2d.DeferredUpdateManager$UpdateRequest.run(DeferredUpdateManager.java:44) at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:136) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3983) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3660) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1151) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:337) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1032) at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:148) at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:637) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:337) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:580) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:150) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:141) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:380) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:235) at sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-2) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:648) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:603) at org.eclipse.equinox.launcher.Main.run(Main.java:1465)
General Information:
reported-by: adsas
anonymous-id: 6aa5d236-7739-36b5-9b06-56a64d82d12d
eclipse-build-id: 4.5.0.I20140918-0330
eclipse-product: org.eclipse.epp.package.modeling.product
operating system: MacOSX 10.9.3 (x86_64) - cocoa
jre-version: 1.7.0_55-b13
The following plug-ins were present on the execution stack (*): 1. org.eclipse.core.databinding.observable_1.4.1.v20140910-2107 2. org.eclipse.core.databinding_1.4.100.v20140910-2107 3. org.eclipse.core.runtime_3.10.0.v20140724-1132 4. org.eclipse.draw2d_3.10.0.201409290206 5. org.eclipse.e4.ui.workbench_1.2.0.v20140905-1352 6. org.eclipse.e4.ui.workbench.swt_0.12.100.v20140908-1525 7. org.eclipse.equinox.app_1.3.200.v20130910-1609 8. org.eclipse.equinox.launcher_1.3.0.v20140415-2008 9. org.eclipse.swt_3.104.0.v20140916-1012 10. org.eclipse.ui_3.107.0.v20140911-1616 11. org.eclipse.ui.ide.application_1.0.600.v20140909-1818 12. org.eclipse.ui.ide_3.10.100.v20140905-0917
Please note that:
- Messages, stacktraces, and nested status objects may be shortened.
- Bug fields like status, resolution, and whiteboard are sent back to reporters.
- The list of present bundles and their respective versions was calculated by package naming heuristics. This may or may not reflect reality.
Other Resources:
- Report: https://dev.eclipse.org/recommenders/committers/confess/#/problems/54c4eefcbee810030da06573
- Manual: https://dev.eclipse.org/recommenders/community/confess/#/guide
Thank you for your assistance. Your friendly error-reports-inbox.
The following incident was reported via the automated error reporting:
code: 0
plugin: org.eclipse.ui_3.107.0.v20140911-1616
message: Unhandled event loop exception
fingerprint: 10c6ef3a
exception class: org.eclipse.swt.SWTException
exception message: Failed to execute runnable (java.lang.StringIndexOutOfBoundsException: String index out of range: 25)
number of children: 0
org.eclipse.swt.SWTException: Failed to execute runnable (java.lang.StringIndexOutOfBoundsException: String index out of range: 25)
at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:139)
at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:4147)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3764)
at org.eclipse.jface.window.Window.runEventLoop(Window.java:832)
at org.eclipse.jface.window.Window.open(Window.java:808)
at org.eclipse.papyrus.infra.widgets.editors.ReferenceDialog.browseAction(ReferenceDialog.java:221)
at org.eclipse.papyrus.infra.widgets.editors.ReferenceDialog.widgetSelected(ReferenceDialog.java:431)
at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:248)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4353)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1061)
at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:4172)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3761)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1151)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:337)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1032)
at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:148)
at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:637)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:337)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:580)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:150)
at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:141)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:380)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:235)
at sun.reflect.NativeMethodAccessorImpl.invoke0(null:-2)
at sun.reflect.NativeMethodAccessorImpl.invoke(null:-1)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(null:-1)
at java.lang.reflect.Method.invoke(null:-1)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:648)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:603)
at org.eclipse.equinox.launcher.Main.run(Main.java:1465)
at org.eclipse.equinox.launcher.Main.main(Main.java:1438)
caused by: java.lang.StringIndexOutOfBoundsException: String index out of range: 25 at java.lang.String.substring(null:-1) at org.eclipse.draw2d.text.TextFlow.getBidiSubstring(TextFlow.java:223) at org.eclipse.gmf.runtime.draw2d.ui.text.TextFlowEx.paintFigure(TextFlowEx.java:157) at org.eclipse.draw2d.Figure.paint(Figure.java:1115) at org.eclipse.draw2d.Figure.paintChildren(Figure.java:1167) at org.eclipse.draw2d.Figure.paintClientArea(Figure.java:1197) at org.eclipse.draw2d.Figure.paint(Figure.java:1117) at org.eclipse.draw2d.Figure.paintChildren(Figure.java:1167) at org.eclipse.draw2d.Figure.paintClientArea(Figure.java:1202) at org.eclipse.gmf.runtime.draw2d.ui.figures.WrappingLabel.paintClientArea(WrappingLabel.java:1104) at org.eclipse.draw2d.Figure.paint(Figure.java:1117) at org.eclipse.draw2d.Figure.paintChildren(Figure.java:1167) at org.eclipse.gmf.runtime.diagram.ui.internal.figures.BorderItemContainerFigure.paintClientArea(BorderItemContainerFigure.java:85) at org.eclipse.draw2d.Figure.paint(Figure.java:1117) at org.eclipse.draw2d.Figure.paintChildren(Figure.java:1167) at org.eclipse.draw2d.Figure.paintClientArea(Figure.java:1202) at org.eclipse.draw2d.Figure.paint(Figure.java:1117) at org.eclipse.draw2d.Figure.paintChildren(Figure.java:1167) at org.eclipse.gmf.runtime.diagram.ui.internal.figures.BorderItemContainerFigure.paintClientArea(BorderItemContainerFigure.java:85) at org.eclipse.draw2d.Figure.paint(Figure.java:1117) at org.eclipse.draw2d.Figure.paintChildren(Figure.java:1167) at org.eclipse.draw2d.Figure.paintClientArea(Figure.java:1202) at org.eclipse.draw2d.Figure.paint(Figure.java:1117) at org.eclipse.draw2d.Figure.paintChildren(Figure.java:1167) at org.eclipse.draw2d.Figure.paintClientArea(Figure.java:1202) at org.eclipse.draw2d.Figure.paint(Figure.java:1117) at org.eclipse.draw2d.Figure.paintChildren(Figure.java:1167) at org.eclipse.draw2d.Figure.paintClientArea(Figure.java:1202) at org.eclipse.draw2d.Figure.paint(Figure.java:1117) at org.eclipse.draw2d.Figure.paintChildren(Figure.java:1167) at org.eclipse.draw2d.Figure.paintClientArea(Figure.java:1202) at org.eclipse.draw2d.Figure.paint(Figure.java:1117) at org.eclipse.draw2d.Figure.paintChildren(Figure.java:1167) at org.eclipse.gmf.runtime.draw2d.ui.internal.graphics.ScalableFreeformLayeredPane.paintClientArea(ScalableFreeformLayeredPane.java:89) at org.eclipse.draw2d.Figure.paint(Figure.java:1117) at org.eclipse.gmf.runtime.draw2d.ui.internal.parts.ThumbnailEx$ThumbnailUpdater.run(ThumbnailEx.java:164) at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:136) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:4147) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3764) at org.eclipse.jface.window.Window.runEventLoop(Window.java:832) at org.eclipse.jface.window.Window.open(Window.java:808) at org.eclipse.papyrus.infra.widgets.editors.ReferenceDialog.browseAction(ReferenceDialog.java:221) at org.eclipse.papyrus.infra.widgets.editors.ReferenceDialog.widgetSelected(ReferenceDialog.java:431) at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:248) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84) at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4353) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1061) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:4172) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3761) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1151) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:337) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1032) at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:148) at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:637) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:337) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:580) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:150) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:141) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:380) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:235) at sun.reflect.NativeMethodAccessorImpl.invoke0(null:-2) at sun.reflect.NativeMethodAccessorImpl.invoke(null:-1) at sun.reflect.DelegatingMethodAccessorImpl.invoke(null:-1) at java.lang.reflect.Method.invoke(null:-1) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:648) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:603) at org.eclipse.equinox.launcher.Main.run(Main.java:1465) at org.eclipse.equinox.launcher.Main.main(Main.java:1438)
General Information:
reported-by: Matteo Merialdo
anonymous-id: 6a779720-b831-3b0c-944e-0fcde9995424
eclipse-build-id: 4.5.0.I20140918-0330
eclipse-product: org.eclipse.epp.package.modeling.product
operating system: Windows8 6.2.0 (x86_64) - win32
jre-version: 1.7.0_51-b13
The following plug-ins were present on the execution stack (*): 1. org.eclipse.core.databinding.observable_1.4.1.v20140910-2107 2. org.eclipse.core.databinding_1.4.100.v20140910-2107 3. org.eclipse.core.runtime_3.10.0.v20140724-1132 4. org.eclipse.draw2d_3.10.0.201409290206 5. org.eclipse.e4.ui.workbench_1.2.0.v20140905-1352 6. org.eclipse.e4.ui.workbench.swt_0.12.100.v20140908-1525 7. org.eclipse.equinox.app_1.3.200.v20130910-1609 8. org.eclipse.equinox.launcher_1.3.0.v20140415-2008 9. org.eclipse.gmf.runtime.diagram.ui_1.8.0.201409241816 10. org.eclipse.gmf_1.7.0.201409241816 11. org.eclipse.gmf.runtime.draw2d.ui_1.9.0.201409241816 12. org.eclipse.jface_3.11.0.v20140822-0942 13. org.eclipse.papyrus.infra.widgets_1.0.1.v201409170932 14. org.eclipse.swt_3.104.0.v20140916-1012 15. org.eclipse.ui_3.107.0.v20140911-1616 16. org.eclipse.ui.ide.application_1.0.600.v20140909-1818 17. org.eclipse.ui.ide_3.10.100.v20140905-0917
Please note that:
- Messages, stacktraces, and nested status objects may be shortened.
- Bug fields like status, resolution, and whiteboard are sent back to reporters.
- The list of present bundles and their respective versions was calculated by package naming heuristics. This may or may not reflect reality.
Other Resources:
- Report: https://dev.eclipse.org/recommenders/committers/confess/#/problems/54c4ef9abee810030da071ab
- Manual: https://dev.eclipse.org/recommenders/community/confess/#/guide
Thank you for your assistance. Your friendly error-reports-inbox.
If there are 2 connections, 1 connection is a straight line while another connection is bent, which looks a bit asymmetric. Similarly for any even number of connections. Instead if user can be given an option to bend both/all the connections in case there are only 2/even connections it will look symmetric.
Animation does not work on Mac OS X (again).
Eclipe 4.5.1 GEF 3.10.1 OS X 10.11.1
For steps to reproduce, see bug #135352
Created attachment 264505 Tree Layout crash
As report at bug 502165, in some case when we move a bendpoint from an edge. The edge is root with tree without closest distance.
use case:
- Create a new ecore diagram using the file > new.
- Create 3 classes 1, 2 and 3.
- Drag a bendpoint => Eclipse is crashed (see attachment)
This seems to come from the validation of the layout. The figure figure LightweightSystem$Rootfigure is constantly invalidate since the scrollbar is growing.
This bug occurs in oxygen and can be reproduced in mars/neon/oxygen version of Papyrus(which use GMF).
Bug 516272 - Support triple-clicks on figures - expose click count from original SWT MouseEvent in Draw2d MouseEvent
The SWT MouseEvent has a count field that expresses the number of times the mouse has been repeatedly clicked, according to the operating system.
This can be used to support triple-clicks. For example, a triple-click could be a step in expanding a selection.
The Draw2D MouseEvent accepts an SWT MouseEvent as an argument to its constructor, but does not copy and expose the original count value. This minor enhancement requests that the value be exposed in Draw2D's shadow of the original MouseEvent.
Due to changes made to the function findMouseEventTargetInDescendantsAt() in Figures.java for Bug 472848, the Snippets view in Eclipse is broken as of Mars.1.
When there are multiple folders of snippets, if a user tries to select a snippet that isn't in the first folder / row, the folder will collapse and open the first folder, making it very difficult to properly select the snippet. As a result, I believe this change should be reverted so that the Snippets view can function properly
See Bug 486925 for more details.
Bug 549626 - SWTGraphics constructor has race condition when taking Clipping from GC with a set Transform
When running the following code fragment in rapid succession (in a PaintListener for example):
Image image = new Image(Display.getCurrent(), 100, 100);
GC imageGC = new GC(image);
Transform transform = new Transform(imageGC.getDevice());
transform.translate(10, 10);
imageGC.setTransform(transform);
imageGC.setClipping(20, 20, 30, 30);
SWTGraphics g = new SWTGraphics(imageGC);
Rectangle r = new Rectangle();
g.getClip(r);
System.out.println(r.toString());
The printed rectangle randomly oscillates between two values:
Rectangle(20.0, 20.0, 30.0, 30.0) Rectangle(20.0, 20.0, 10.0, 30.0)
It looks like some sort of a race condition. The graphics painted onto the Image through g are also incorrectly clipped most of the time. Manually overwriting the clipping on the SWTGraphics after it is constructed solves the issue:
g.setClip(new Rectangle(20, 20, 30, 30));
When there are two different Labels displaying the same single character text, and the two Labels have different foreground colors set to them, the second Label's foreground color will still follow the first Label's foreground color.
This is found to happen in v3.10.100, but issue still persists when changing to v3.12.0 and v3.13.0
The observed behavior of the issue:
- For each Labels that displays same one character texts, they will have the same foreground color
- The foreground colors of the Labels that displays the same one character texts will follow the first
setForegroundColor()color that was passed to that Label. For example: firstLabel - No foreground color set secondLabel- Blue foreground color set thirdLabel - Red foreground color set All three labels will have blue foreground color.
Build ID: 3.2.2
Create a scrollbar with e.g. minimum: -50000000 maximum: 50000000 value: 0 The thumb will not be drawn in the middle but over the up arrow button. It cannot be dragged to the middle either.
A path which starts on the border of an obstacle should go straight to its destination unless that requires it to travel back through the obstacle which it originates from. For example, the carry-over wires in the 4-bit adder loop back up to the next adder.
Possible solution may be to move the path endpoint out 1 pixel, or modify the obstacle intersection test.
Created attachment 232633 Runnable example
Scaling in GEF 3.x (draw2d) is very frustrating. In addition to imprecise drawing due to the integer coordinates, it also draws weird scaled fonts and ugly rectangles.
So I have decided to use the SWTGraphics instead of the emulated ScaledGraphics. This resolved font drawing but it has its own pitfalls. You can run the attached file with simple example to see it.
When using pure GC, scaling is nice and clean. The rectangle is always drawn with line width 1 and mainly its all edges are always drawn.
On the other hand, with Draw2d's SWTGraphics, the rectangle is sometimes cropped?!, the line width jumps from 1 to 2 (try to scale to with mouse wheel to something above 2).
What is wrong here??
Build ID: I20060512-1600
Steps To Reproduce: See source.
More information: There seems to be no way to obtain text size from Graphics. One must invoke textExtent() of the underlying GC object, which is error-prone (as graphics.setFont() does not immediately propagate font setting to GC, so gc.textExtent() will return bogus results unless you made a dummy graphics.drawText() first).