Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 314750 - [cocoa, gef] RulerComposite is detecting Mac OS X incorrectly, only Carbon not Cocoa
Summary: [cocoa, gef] RulerComposite is detecting Mac OS X incorrectly, only Carbon no...
Status: RESOLVED INVALID
Alias: None
Product: GEF
Classification: Tools
Component: GEF-Legacy GEF (MVC) (show other bugs)
Version: unspecified   Edit
Hardware: Macintosh Mac OS X
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Alexander Nyßen CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-05-27 14:37 EDT by Justin Dolezy CLA
Modified: 2011-02-16 13:57 EST (History)
1 user (show)

See Also:

Attachments
Patch to better detect Mac OS X (1.06 KB, text/plain)
2010-05-27 14:38 EDT, Justin Dolezy CLA 		no flags Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Justin Dolezy CLA 2010-05-27 14:37:55 EDT 
Build Identifier: I20100312-1448

As mentioned in https://bugs.eclipse.org/bugs/show_bug.cgi?id=311781 RulerComposite.calculateRulerTrim(Canvas) is only picking up Carbon when applying a Mac workaround, should also include Cocoa.

Reproducible: Always
Comment 1 Justin Dolezy CLA 2010-05-27 14:38:41 EDT 
Created attachment 170241 [details]
Patch to better detect Mac OS X

Patch attached.
Comment 2 Alexander Nyßen CLA 2010-12-16 18:07:34 EST 
Justin, do you have something to reproduce that the fix is actually needed on Cocoa as well? Carbon and Cocoa seem to be quite different worlds...
Comment 3 Justin Dolezy CLA 2010-12-17 03:50:22 EST 
Don't think I do actually; can't remember what this was all about! I think there was some other issue that did affect Cocoa/Mac but only Carbon was being detected so I went and looked for all Carbon references assuming they ought to pick up Cocoa as well... but that's no necessarily so...
Comment 4 Alexander Nyßen CLA 2010-12-17 03:55:30 EST 
Yes, that's the reason I ask. I already sorted out one "false positive" yesterday (see bug #313319) and I want to prevent that we incorporate more workarounds (with potential side-effects) than needed.
Comment 5 Alexander Nyßen CLA 2011-02-16 13:57:14 EST 
Having consulted Scott Kovatch of the SWT team and having investigated the Scrollable#computeTrim() implementations for both platforms, it seems a respective patch for Cocoa is not needed. 

Interestingly I can also not reproduce a situation in which the Carbon workaround does have any effect (the snippet seems to compensate the effect of Scrollable#inset(), which only does something in case a border is set, which is not the case with RulerViewer's FigureCanvas). 

However, as Carbon is an unsupported platform for 3.7 and we are going to remove all workarounds anyway in the near future, I will leave the workaround for Carbon in place (I added a comment to it to indicate it does not apply to Cocoa) and close this one as INVALID.