Bugzilla – Full Text Bug Listing
| Summary: | [Font/Colour] Still too many lines with uncoordinated colors | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Andre Weinand <andre_weinand> | ||||||||||
| Component: | UI | Assignee: | Michael Van Meekeren <michaelvanmeekeren> | ||||||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||||||
| Severity: | normal | ||||||||||||
| Priority: | P2 | CC: | bill, boris, channingwalton, cmlenz, eclipse, ulrich | ||||||||||
| Version: | 3.0 | ||||||||||||
| Target Milestone: | 3.0 M9 | ||||||||||||
| Hardware: | Macintosh | ||||||||||||
| OS: | Mac OS X - Carbon (unsup.) | ||||||||||||
| Whiteboard: | |||||||||||||
| Bug Depends on: | |||||||||||||
| Bug Blocks: | 56476 | ||||||||||||
| Attachments: |
|
||||||||||||
|
Description
Andre Weinand
Created attachment 8325 [details]
Too many lines...
currently we do not change the color of the views local toolbar, so that it does not take on any bright color chosen for the tab color, and so that when a tab becomes active and is deactivated the toolbar remains a consistent color. I think this is a better scenario then setting the background of the toolbar to a non-default color. As for the blue border around the widget with focus, the workbench would need SWT support to turn that off. Yes, the local toolbar isn't too bright, but it's way too dark. Please, see the following attachment. This is the default look of I20040318. It hurt's a typical Mac user's eyes :-) Created attachment 8717 [details]
default look of I20040318
However, after 5 minutes of tweeking (including applying a patch to SWT) it looks like this (see the following screenshot). Created attachment 8718 [details]
tweaked look
This does not only improve on the default look of I20040318 but it actually looks better than any previous version of Eclipse on Mac OS X. What I did: - changed the color of the active tab to Aqua blue (which matches the hardcoded color of other UI elements) - reversed the gradient for non-active tabs: the light color now matches the color of the local toolbar. This isn't perfect because the background color of the local toolbar is a pattern, and not a solid color, but it avoids the dark local toolbar. - removed the focus ring of StyledText which avoids the double focus border in editors. However, this does not solve the problem of a double focus border in trees and tables. - set the default font to the small Mac default font. These four small changes would bring the Eclipse experience on Mac OS to an acceptable level. Yes, my changes contain two debatable "hacks". But I wouldn't like to see the current Mac look ship for the final Eclipse 3.0. I'm willing to help in order to get these four modifications into M9. So I suggest to reopen this bug to track these four modifications. I like what you're suggesting Andre, feels cleaner/lighter :-) I also agree with the comment you made in bug #52498 regarding the non anti-aliased curvy lines - they are really nasty. Andre, I much prefer the tweaked look. Go for it. It seems to me that the 'new look' has been driven by a Windows XP system and not really considered other operating system look and feels. The current 'New Look' is really ugly in comparison to other Mac OS X applications, and the work Andre has done in updating that goes a long way to fixing some of these issues. Given that part of 3.0's goals is to make Eclipse run as a 'real' Mac application, not addressing an app's look-and-feel for that platform seems laughable. And if this bug remains at 'resolved later' then it is unlikely to be addressed prior to the release of 3.0, which would therefore fail the Mac OS X goal. Wow. Pretty amazing. Not only in 3.0M8 a lot clunkier looking than 3.0M7, but it is also noticeably slower and goes into spin mode much more often.... I agree, the new look is hideous on OS X. Since Eclipse 3.0 is supposed to officially support OS X, it would be nice if they would do just that - support OS X, and not just pay us lip service. I have to add a "me too" here - M8 has many excellent new features, but the current UI is remarkably bad on OSX. Andre's changes should be incorporated into M9. I raised bug 56476 to discuss the hideousness of the UI on the Mac platform, aside from just the lines (which this bug raises). I've raised it as a major priority, and I suggest that you also attach comments to that bug (with votes, if necessary). Re bug 56476, I've attached an attachment with a much nicer (IMNSHO) set of colours for the tab gradients; you can download it as an Eclipse preferences file from https://bugs.eclipse.org/bugs/attachment.cgi?id=8973&action=view Not specifically a lines comment, but the colours work much nicer. Anyone on this bug fancy taking a look? Up till now we have applied a common (read: cross platform) color mapping to eclipse. So the same OS colors (such as widget background or selection color) were used for all platforms. During M9 we plan to branch out tweak colors where needed and use different options on different platforms if necessary. I would like to see votes here for what colors to choose, however we can not pick from RGBs as eclipse must honour the color theme from the OS. So we will likely find the closest match. I will attach a simple SWT app that shows the colors that are made available across platforms if you are interested. Created attachment 8975 [details]
SWT Color Viewer
Compile and Run in a project built against SWT, may need to put the SWT shared
library on the path for the VM.
Michael, I don't understand comment #16. You say: "I would like to see votes here for what colors to choose, however we can not pick from RGBs as eclipse must honour the color theme from the OS." o Why can RGBs not be used? o Why are you assuming that there is a colour theme for the OS? There's no such 'theme' in OS X other than the defaults, unlike X-Windows or MS-Windows. The defaults (see below) relatively closely match those for a default Carbon app on Mac OS X, and are represented as gray %, which is an easy number to calculate based on whichever colour model you're using. My comment from 56476: Using the title bar colours from Text Edit and a couple of other carbon apps works quite well: o Inactive part background begin/end (F0,F0,F0) -- 94% gray o Active part background begin (E6,E6,E6) -- 90% gray o Active part background end (CC,CC,CC) -- 80% gray These should be easy to emulate in SWT, regardless of how it works and whether or not they use RGB. Response to comment #18 (also please keep in mind that I am not arguing that what Andre proposes looks worse or better) There aren't many techincal reasons why RGBs can not be used. I will try and explain what things look like from my perspective see if they make sense: 1) RGBs can be used, but hardcoding any RGB in the workbench has limitations: i) eclipse is sensitive to user color changes ii) eclipse is sensitive to Apple shipping different colors with the OS iii) eclipse has a hard requirement to ensure that users with accessibility requirements such as High Contrast color settings etc... are supported. Any time we hard code a color we will not be supporting users with specific color issues (color blindness etc..) If there is an RGB defined in the OS for this particular color that we want to match we will be out of date as soon as the user modifies colors, or Apple ships another copy of the OS choosing different colors, for example if we wanted tab background to be the same as the color for the title background we would use the SWT color mapping named COLOR_TITLE_BACKGROUND_GRADIENT, in SWT they call the OS to get this color and it may change (see class Display in SWT), here is the code that gets the color: case SWT.COLOR_TITLE_BACKGROUND_GRADIENT: OS.GetThemeBrushAsColor((short) OS.kThemeBrushPrimaryHighlightColor, (short)getDepth(), true, rgb) ; break; Either way the workbench is not sensitive to color changes in the OS, SWT may be in some cases, but at least that will be contained in one place. 2) I realize there is no formal official theme for OS X, however I prefer to at least keep that decision centralized in the SWT component 3) yes SWT is emulating OS X colors (see Display.java) and we map to these, if you disagree with SWTs choices of any givin color bugs can be reported against this in SWT. Re #19, I don't think the colours should be hard coded such that they cannot be changed. I was merely suggesting that they have a better default value than they do at the moment. "2) I realize there is no formal official theme for OS X, however I prefer to at least keep that decision centralized in the SWT component" Sounds entirely reasonable -- can we apply those changes there? "3) yes SWT is emulating OS X colors (see Display.java) and we map to these, if you disagree with SWTs choices of any givin color bugs can be reported against this in SWT." I suggested the colours that I'd recommend for the begin and end active/inactive tabs (and provided the preferences with the colours defined). I don't know how they'd map to the Display.java file because I'm not that familiar with the code, but I imagine that there's some kind of initial default value you're emulating -- so can we change it there instead? Obviously the defaults are being set *somewhere*, but I don't know where :-) The following colour: o Inactive part background begin/end (F0,F0,F0) -- 94% gray is the same as the SWT colour named COLOR_WIDGET_BACKGROUND. I think that the inactive part background begin and end should be set to the same value as COLOR_WIDGET_BACKGROUND. It also sorts out nicely the font related problem, because many icons in the toolbar use COLOR_WIDGET_BACKGROUND as their background, so making the Workbench Appearance 'Inactive part background begin/end' having this will actually clean up some of the colour issues with this bug (specifically, that one defined in comment #1) I've not found a nice way of obtaining the other active tabs at present. However, I think that the idea of keeping the Eclipse UI synchronised is going to be difficult anyway; for example, the 'COLOR_WIDGET_BACKGROUND' is liked to the Mac OS X property 'kThemeBrushButtonFaceActive', which is just a random grey that looks good. Additionally, the Mac OS X properties don't map directly to UI components in Eclipse; for example, there are separate foreground/background for tabs, for titles, and other components -- but in Eclipse, they seem to all be the same 'Inactive part baground'. the local toolbar and background issue is fixed. As for getting rid of the lines, this will not be changed. |