Community
Participate
Working Groups
Build Identifier: I20100312-1448 Guide markers are only half visible on Cocoa - they extend below the bottom/right edge of the ruler. Issue is due to the following method not taking Cocoa into account when detecting Mac OS X: > private static Rectangle calculateRulerTrim(Canvas canvas) { > if ("carbon".equals(SWT.getPlatform())) { //$NON-NLS-1$ Will supply a patch changing the offending line to: > if (Platform.OS_MACOSX.equals(Platform.getOS())) { Reproducible: Always Steps to Reproduce: 1. Open a GEF editor with a ruler on Cocoa 2. Click in the ruler area to create a guide 3. Observe that the guide is only partly visible
Created attachment 169024 [details] Image showing "truncated" guide markers on Cocoa
Created attachment 169025 [details] Image showing correct guide markers on Carbon
Have just tried running with the amended line and I can see no discernible difference! Stepped through in Carbon and Cocoa and the calculated trim rectangle is the same as the default case: 0,0,0,0 - at least on Leopard it is. If this is old code it might be doing something useful on Tiger? > public static Rectangle calculateRulerTrim(Canvas canvas) { > if (Platform.OS_MACOSX.equals(Platform.getOS())) { > Rectangle trim = canvas.computeTrim(0, 0, 0, 0); > trim.width = 0 - trim.x * 2; > trim.height = 0 - trim.y * 2; > return trim; > } > return new Rectangle(0, 0, 0, 0); >} On Leopard the computeTrim returns 0,0,15,15 for both Carbon and Cocoa. The problem I'm seeing appears to be caused by something other than this, ruler layout perhaps? Not too familiar with this ruler stuff... I've attached images so you can see what I'm referring to.
Created attachment 169283 [details] Side-by-side closeup comparison of the guide figures I've attached an image showing a closeup of the Carbon and Cocoa guide figures, side-by-side for easy comparison. Seems to me that the issue could actually be to do with the colours selected for drawing the guide?
The theory about the colours appears to be correct. I simply ran a little code to print the color values used by the GuideFigure: > System.out.println(SWT.getPlatform() + ":" + //$NON-NLS-1$ > "\nbuttonLightest = " + ColorConstants.buttonLightest.getRGB() + //$NON-NLS-1$ > "\nbuttonDarker = " + ColorConstants.buttonDarker.getRGB() + //$NON-NLS-1$ > "\nbuttonDarkest = " + ColorConstants.buttonDarkest.getRGB() //$NON-NLS-1$ > ); And this is what we get: cocoa: buttonLightest = RGB {255, 255, 255} buttonDarker = RGB {147, 147, 147} buttonDarkest = RGB {0, 0, 0} carbon: buttonLightest = RGB {204, 204, 204} buttonDarker = RGB {102, 102, 102} buttonDarkest = RGB {51, 51, 51} Basically the cocoa colours are very different which I believe explains the different appearance. Why there is this large difference is probably a question for the SWT team.
The issue here isn't just to do with the colours, although that is part of it. It turns out that in the GuideFigure drawing code, where it draws the 'V' or '>' part of the guide (depending on whether vertical/horizontal) it is using drawLine() to draw each point - these calls are not actually drawing anything on Cocoa where P1 = P2. For example, where we have: > setForegroundColor(ColorConstants.buttonDarker); > drawLine(clientArea.x + 1, clientArea.y + 1, clientArea.x + 1, y + 4); > drawLine(clientArea.x + 2, clientArea.y + 1, clientArea.x + 7, y + 1); > drawLine(clientArea.x + 7, clientArea.y + 2, clientArea.x + 7, y + 2); > drawLine(clientArea.x + 2, clientArea.y + 5, clientArea.x + 2, y + 5); > drawLine(clientArea.x + 3, clientArea.y + 6, clientArea.x + 3, y + 6); the last 3 calls do not actually draw anything, however when replaced with: > setForegroundColor(ColorConstants.buttonDarker); > drawLine(clientArea.x + 1, clientArea.y + 1, clientArea.x + 1, y + 4); > drawLine(clientArea.x + 2, clientArea.y + 1, clientArea.x + 7, y + 1); > drawPoint(clientArea.x + 7, clientArea.y + 2); > drawPoint(clientArea.x + 2, clientArea.y + 5); > drawPoint(clientArea.x + 3, clientArea.y + 6); then we see the figure draw correctly. Leaving the ColorConstants as they are, using the "bad" System colours, then the ruler figure looks rather "binary" and washed out, but shoehorning the correct colours into ColorConstants results in the correct figure. I'll attach images showing this. I'll raise a new bug against SWT for the System colours. Re the bad drawing of the RulerFigure, I can supply a patch changing the drawLine(x,y, x,y) calls with drawPoint calls. I think this shouldn't be a Cocoa specific piece but a global change - I can verify whether it still draws the same on win32 for XP/Vista/7. Alternatively another SWT bug needs to be raised as to why o.e.swt.graphics.GC.drawLine(x,y, x,y) draws nothing under Cocoa.
Created attachment 169611 [details] Correct figures with drawLine->drawPoint change, also showing colour issue
Created attachment 169612 [details] Zoomed version of correct figures with drawLine->drawPoint change, also showing colour issue
Re the system colours, have raised a new SWT bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=314044
(In reply to comment #6) > It turns out that in the GuideFigure drawing code, where it draws the 'V' or > '>' part of the guide (depending on whether vertical/horizontal) it is using > drawLine() to draw each point - these calls are not actually drawing anything > on Cocoa where P1 = P2. > Alternatively another SWT bug needs to be raised as to why > o.e.swt.graphics.GC.drawLine(x,y, x,y) draws nothing under Cocoa. Carbon had this bug as well, and the fix never propagated to Cocoa. This should do it: ### Eclipse Workspace Patch 1.0 #P org.eclipse.swt Index: Eclipse SWT/cocoa/org/eclipse/swt/graphics/GC.java =================================================================== RCS file: /cvsroot/eclipse/org.eclipse.swt/Eclipse SWT/cocoa/org/eclipse/swt/graphics/GC.java,v retrieving revision 1.78 diff -u -r1.78 GC.java --- Eclipse SWT/cocoa/org/eclipse/swt/graphics/GC.java 7 May 2010 19:40:38 -0000 1.78 +++ Eclipse SWT/cocoa/org/eclipse/swt/graphics/GC.java 24 May 2010 22:17:00 -0000 @@ -1147,6 +1147,10 @@ */ public void drawLine(int x1, int y1, int x2, int y2) { if (handle == null) SWT.error(SWT.ERROR_GRAPHIC_DISPOSED); + if (x1 == x2 && y1 == y2 && data.lineWidth <= 1) { + drawPoint(x1, y1); + return; + } NSAutoreleasePool pool = checkGC(DRAW); try { NSBezierPath path = data.path;
Is this patch already in one of the RCs or still to be released?
(In reply to comment #9) > Re the system colours, have raised a new SWT bug: > https://bugs.eclipse.org/bugs/show_bug.cgi?id=314044 Make sure you move the SWT patch over to this Bug and indicate it's priority.
(In reply to comment #11) > Is this patch already in one of the RCs or still to be released? No, it's not checked in yet. Given the high bar for RC3 I can't promise it will go in, but I will talk to Silenio today.
Should we move this bug to SWT? I will commit the change for drawLine for 3.6.1.
I'd really like a solution for GuideFigure for 3.6 - I can supply a patch changing the drawLine calls with drawPoint if there's still time for it to make it. The larger SWT patch can then be 3.6.1 I guess.
(In reply to comment #15) > I'd really like a solution for GuideFigure for 3.6 - I can supply a patch > changing the drawLine calls with drawPoint if there's still time for it to make > it. I can't help on GEF, but that's probably the better bet for now. We're only taking crash fixes for SWT at this point.
Created attachment 170240 [details] GuideFigure patch to use drawPoint instead of drawLine where relevant Attaching a patch, hopefully you can include this for 3.6, Randy.
(In reply to comment #10) > Carbon had this bug as well, and the fix never propagated to Cocoa. This should > do it: Fix was checked into HEAD > 20100714 in SWT. I'm not changing the status in case there's some additional GEF change that needs to happen.
Hi Justin, can you confirm the SWT fix was sufficient?
(In reply to comment #19) > Hi Justin, can you confirm the SWT fix was sufficient? Moving to 3.6.2 for now.
Sorry for the delay... that patch didn't make it into 3.6 as far as I could tell and I think Scott's comment confirms that (Fix was checked into HEAD > 20100714 in SWT). I'll need to download the 3.6.1 SWT libs and give them a try, hopefully soon.
Created attachment 181069 [details] Image showing how the guide figure is painting with SWT 3.6.1 Unfortunately it doesn't look like the SWT change fixes this particular issue. Attached image showing how the guide figure is painting with SWT 3.6.1.
The fix was put into HEAD, which means it's in 3.7. It didn't make it into the 3.6 maintenance branch. I'll clone the bug so we have something to track it.
Created attachment 185204 [details] Screenshot recorded with Eclipse 3.7 N20101214
As demonstrated by my latest attachment, the issue seems to be resolved with Eclipse 3.7 N20101214. Resvoling as "INVALID" as it seems to have been an SWT issue.
Changing resolution from invalid to fixed (even if no GEF problem was the cause), because the problem indeed affected GEF and from the summary this may otherwise misleading.
