Community
Participate
Working Groups
Build ID: I20090515-1143 Steps To Reproduce: 1.Install GEF example plug-ins 2.Create Shapes Diagram file with File -> New -> Example 3.Drop a rectangle or ellipse into the diagram 4.Mouse down on the diagram element, and drag the element to a new location A black rectangle the size of the bounding box for the ellipse or rectangle is shown when dragging. Correct behavior is for the item itself to be shown when dragging, not a black box. More information: Seems to be a new problem with the Mac 3.5 (Galileo) version. Was not a problem with Ganymede.
sounds like a recurrence of bug 262797
I've seen this problem since M6 and it still seems to exist in RC3. This makes for ordered drag and drop worthless for a GridLayout since you can't see the location to drop something.
There doesn't seem to be any activity on this bug? It is not the fixed by 262797. Is there a plan on fixing this before 3.5 is released?
(In reply to comment #2) > I've seen this problem since M6 and it still seems to exist in RC3. So this bug was not there in GEF 3.5 M5 and started in GEF 3.5 M6? (In reply to comment #3) > Is there a plan on fixing this before 3.5 is released? We are past RC4, so we need to look at fixing in SR1 (GEF 3.5.1)
I don't know if it existing in m5 since m6 was the first version I installed on the mac.
(In reply to comment #5) > I don't know if it existing in m5 since m6 was the first version I installed on > the mac. Is it the first version you've -ever- installed on a mac? or just the first version of GEF 3.5?
It is the first mac version of the 64 bit with JDK 1.6 that I tried it with since our product needed jdk 1.6. I don't know if the problem has always existed on the mac version in 32 bit versions.
(In reply to comment #7) > It is the first mac version of the 64 bit with JDK 1.6 that I tried it with > since our product needed jdk 1.6. > I don't know if the problem has always existed on the mac version in 32 bit > versions. I suspect it may have, because the feedback uses XOR raster ops to paint by default, and SWT states that it's fundamentally unsupportable on mac OS X Carbon as their reason for deprecating GC.setXORMode(). org.eclipse.draw2d.FigureUtilities.makeGhostShape(Shape) is used to make feedback figures using XOR mode, and should be changed to use alpha blending instead. However, the effect is different and would be inherited by others who may complain since it "worked fine for them" on Windows.
Does this mean it stays like this or can we have a if checking for macos and do ghost images differently? thanks
> ...and SWT states that it's fundamentally unsupportable on mac OS X > Carbon as their reason for deprecating GC.setXORMode(). It seems like Carbon itself is (will be) deprecated, so SWT should eventually slap a @deprecated on that @deprecated. Cocoa supports XOR, although it doesn't seem like SWT has invoked it in their implementation.
Reviving this one - another Cocoa problem for GEF. GEF is looking better on Cocoa with the latest 3.6.x builds but it's really ugly to drag figures around on the canvas and have black rectangles. On Carbon we're getting a nice transparent grey rectangle so I guess it's the old XOR thing again. Is there anything / workaround that could be done on this? Or is it a SWT dependency?
It would be great to get this fixed. Running GEF on Cocoa is really ugly with black selection boxes. Any pointers to get me started on a patch? Or is it not possible to fix?
Black rectangle appears because of XOR mode set on graphics. Don't set the XOR mode and instead just set the alpha on the feedbackfigure in te paintFigure(...) method
(In reply to comment #13) > Black rectangle appears because of XOR mode set on graphics. > Don't set the XOR mode and instead just set the alpha on the feedbackfigure in > te paintFigure(...) method Thanks for the heads-up, Alex. I did just that, and it works. It would be good to fit this stuff into GEF at core, though with a check to see if it's running on Cocoa.
The missing xor painting functionality on Cocoa was contributed by Scott as part of bug #332872. Verified that with Eclipse 3.7 N20101218-2000 this problem does no longer occur.
Tested on Eclipse 3.7 I20110127-2034 and GEF 3.7 I201101272050. I can confirm that this now works as expected. Thanks!
