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

Bug 314044

Summary:

[cocoa] Display.getSystemColor() returns greatly different colors compared to Carbon

Product:

[Eclipse Project] Platform

Reporter:

Justin Dolezy <justin>

Component:

SWT

Assignee:

Platform-SWT-Inbox <platform-swt-inbox>

Status:

CLOSED WONTFIX

QA Contact:

Severity:

major

Priority:

CC:

lshanmug, skovatch

Version:

3.5

Keywords:

triaged

Target Milestone:

---

Hardware:

Macintosh

OS:

Mac OS X

Whiteboard:

stalebug

Attachments:

Description	Flags
Spreadsheet with row colour highlighting indicating trivial/minor/major system colour differences between Carbon and Cocoa	none

Description Justin Dolezy

2010-05-23 12:01:18 EDT

Build Identifier: I20100312-1448

This is something I've discovered having raised GEF bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=313315.

It turns out that Cocoa is returning many standard system colours that are greatly different causing painting issues for widgets that depend on these. For example, WIDGET_DARK_SHADOW is black and WIDGET_HIGHLIGHT_SHADOW is white - not very useful!

Here's the full list to compare, will also attach as a spreadsheet, highlighting the rows with differences:

> 	carbon:	cocoa:
> WIDGET_FOREGROUND 	 Color {0, 0, 0}	 Color {0, 0, 0}
> WIDGET_BACKGROUND 	 Color {230, 230, 230}	 Color {232, 232, 232}
> WIDGET_BORDER     	 Color {0, 0, 0}	 Color {0, 0, 0}
> WIDGET_DARK_SHADOW	 Color {51, 51, 51}	 Color {0, 0, 0}
> WIDGET_NORMAL_SHADOW 	 Color {102, 102, 102}	 Color {147, 147, 147}
> WIDGET_LIGHT_SHADOW  	 Color {153, 153, 153}	 Color {232, 232, 232}
> WIDGET_HIGHLIGHT_SHADOW 	 Color {204, 204, 204}	 Color {255, 255, 255}
> WIDGET_LIST_BACKGROUND 	 Color {255, 255, 255}	 Color {255, 255, 255}
> WIDGET_LIST_FOREGROUND 	 Color {0, 0, 0}	 Color {0, 0, 0}
> WIDGET_LIST_SELECTION  	 Color {181, 213, 255}	 Color {180, 213, 255}
> WIDGET_LIST_SELECTION_TEXT 	 Color {0, 0, 0}	 Color {0, 0, 0}
> WIDGET_INFO_BACKGROUND 	 Color {255, 255, 225}	 Color {255, 255, 225}
> WIDGET_INFO_FOREGROUND 	 Color {0, 0, 0}	 Color {0, 0, 0}
> WIDGET_TITLE_BACKGROUND 	 Color {56, 117, 215}	 Color {56, 117, 215}
> WIDGET_TITLE_BACKGROUND_GRADIENT 	 Color {181, 213, 255}	 Color {180, 213, 255}
> WIDGET_TITLE_FOREGROUND 	 Color {0, 0, 0}	 Color {0, 0, 0}
> WIDGET_TITLE_INACTIVE_BACKGROUND 	 Color {208, 208, 208}	 Color {212, 212, 212}
> WIDGET_TITLE_INACTIVE_BACKGROUND_GRADIENT 	 Color {208, 208, 208}	 Color {212, 212, 212}
> WIDGET_TITLE_INACTIVE_FOREGROUND 	 Color {69, 69, 69}	 Color {127, 127, 127}


Reproducible: Always

Comment 1 Justin Dolezy

2010-05-23 12:03:54 EDT

Created attachment 169613 [details]
Spreadsheet with row colour highlighting indicating trivial/minor/major system colour differences between Carbon and Cocoa

Comment 2 Scott Kovatch

2010-05-24 18:18:28 EDT

In Carbon the COLOR_WIDGET_xxx_SHADOW values are hard-coded constants because there was no Appearance Manager constant that corresponded to the value, but in Cocoa we use standard NSColor-generated values.

For COLOR_TITLE_INACTIVE_FOREGROUND, Carbon is using kThemeTextColorDocumentWindowTitleInactive vs. Cocoa's disabledControlTextColor. I would argue Carbon isn't right here, as the window title has nothing to do with control 'titles'.

Comment 3 Scott Kovatch

2010-05-24 18:45:31 EDT

(In reply to comment #2)
> For COLOR_TITLE_INACTIVE_FOREGROUND, Carbon is using
> kThemeTextColorDocumentWindowTitleInactive vs. Cocoa's
> disabledControlTextColor. I would argue Carbon isn't right here, as the window
> title has nothing to do with control 'titles'.

Sorry, this remark is wrong... according to the Northover/Wilson SWT book, COLOR_TITLE_xxx do refer to the title bar of a window, as opposed to COLOR_WIDGET_xxx which are for controls in the window. 

In any event, disabledControlTextColor is more correct than the Carbon version.

Comment 4 Lakshmi P Shanmugam

2017-07-03 07:46:09 EDT

Bug triaged, visit https://wiki.eclipse.org/SWT/Devel/Triage for more
information.

Comment 5 Eclipse Genie

2020-06-04 18:25:49 EDT

This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug.

If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.

--
The automated Eclipse Genie.