Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 325012

Summary: Colors returned by Mac Color Dialog get shifted based on calibrated color space
Product: [Eclipse Project] Platform Reporter: Chris Williams <chris.a.williams>
Component: SWTAssignee: Scott Kovatch <skovatch>
Status: RESOLVED FIXED QA Contact:
Severity: minor    
Priority: P3 CC: eclipse.felipe, Silenio_Quarti
Version: 3.6   
Target Milestone: 3.7 M2   
Hardware: Macintosh   
OS: Mac OS X   
Whiteboard:

Description Chris Williams CLA 2010-09-10 17:06:50 EDT 
Build Identifier: I20100608-0911

The color dialog on Mac takes in an RGB value and generates an NSColor using device colorspace, then the user manipulates the values manually. The NSColor is then transformed using the calibrated colorspace and then converted into an RGB object. That conversion leads to a shifting of values. In cases where the user is using the eyedropper, this is probably the correct way to handle things, but if the user is manually entering HSB/RGB values then we may want to retain the value exactly.

Reproducible: Always

Steps to Reproduce:
1. Open a color dialog
2. Enter in 190, 0, 19 in HSB
3. Returned RGB value gets mapped to 190,0,14 for me when passed back into next open of color dialog.
Comment 1 Felipe Heidrich CLA 2010-09-13 10:06:08 EDT 
Not sure I understood the problem.

You open a same ColorDialog two times.
The first time, you open the dialog, you chose a color in HSB and press okay.
The second time, you open the dilaog and it starts with a color a bit different than the color you chose in the first interaction.

Is that the problem ?
Comment 2 Chris Williams CLA 2010-09-13 10:22:42 EDT 
Yes, that's the basic issue, Felipe. We have syntax coloring preference pages where users are clicking a color box (like a ColorSelector) and they manually edit the HSB values. When they click again, the values have shifted.

Personally I can see how it's confusing for a user, but I'm not 100% sure how to handle it. If they're editing HSB/RGB values manually, we probably want to retain that. If they're using an eyedropper, we probably do want to shift.

You can see the shift in ColorDialog.open, it assumes the input RGB is device and shifts the output using the calibrated colorspace:

	if (rgb != null) {
		NSColor color = NSColor.colorWithDeviceRed(rgb.red / 255f, rgb.green / 255f, rgb.blue / 255f, 1);
		panel.setColor(color);
	}
	...
	if (selected) {
		NSColor color = panel.color();
		if (color != null) {
			color = color.colorUsingColorSpaceName(OS.NSCalibratedRGBColorSpace);
			rgb = new RGB((int)(color.redComponent() * 255), (int)(color.greenComponent() * 255), (int)(color.blueComponent() * 255));
		}
	}
	return rgb;
Comment 3 Scott Kovatch CLA 2010-09-13 11:56:10 EDT 
Actually, this is a general problem in the SWT. We're not being consistent about which color space we use. In most places we use NSDeviceRGBColorSpace for things like images but in others we use NSCalibratedRGBColorSpace. I'm not 100% sure which is better but we definitely should use the same one everywhere.
Comment 4 Scott Kovatch CLA 2010-09-13 14:47:42 EDT 
I will fix this bug with a constant change, since it's a one-liner, but I'm going to open a new bug on NSColorSpace consistency.
Comment 5 Scott Kovatch CLA 2010-09-13 14:49:24 EDT 
Fixed > 20100913.