Community
Participate
Working Groups
When selecting a color, the user only has access to "hard-coded" colors. I don't know the RGB value for "widget background" so it would be a lot easier if I could choose it from a drop-down list of system color choices. Also, this way it would update if I change my OS color scheme, for example high- contrast mode.
Are you referring to the color selection dialog?
Obviously I couldn't be referring to the native dialog :-). But, the UI from which the native dialog is launched (currently a button with the color) could be changed. Instead, use a Drop-Down style button, which has the system colors enumerated (and previewed), and then a More... choice. Choosing More.. couuld open the system dialog.
Ok, ok... smartass. :)
I would consider this part of the new Look & Feel. The usage of color in the new L&F is going to be controversial, and there needs to be ways to map certain choices back to OS constants, not fixed RGBs. Most notably, WIDGET_BACKGROUND.
In the color definition extension point you can declare the value of a color to be that of a system constant. The majority of the new look colors will be declared in this fashion. The preference page is for user customization. The average user isn't going to know (or care) what WIDGET_BACKGROUND means. They know the color the want. If they don't like their choice they have reset, which takes them back to the original (defined in terms of an SWT constant) value.
The most annoying color choice IMO is the view toolbars. They are now a slightly lighter shade than the rest of the widgets. I would like to be able to set the toolbars back to widget_background. Obviously the implementation details do not need to be exposed to the user. Perhaps some different names could be used, or even a preview picture of the colors.
We've been working on the notion of themes for eclipse - where you can switch between sets of active colors and customize them (see the appearance page in the latest IBuild - there'll be a theme combo at the top). Perhaps a good answer for your problem is to define a theme that uses the base system colors instead of lighter blends for people who don't like the new look choice. The color and theme work has gone over budget already... I doubt very much that I'm going to have time to address this request for 3.0.
Marking as later. Will revisit post 3.0
I have tried 0318. It is extremely annoying that view toolbars are not mapped to widget_background, and it is difficult to get them to look right. The user must: 1) Open display properties Dialog 2) Click on Appearance Tab 3) Click on "Advanced" Dialog 4) Select "3D Objects" from the dropdown list 5) Drop down "Color 1" 6) Select "Other" 7) Now copy the RGB values from that color dialog to the preferences dialog. InactivePartBackgroundEnd should be set to WIDGET_BACKGROUND by default as a workaround should this feature not be scheduled for 3.0.
I only own the API, not the selection of colors. Opening a new bug to address changing the color. I won't be able to address this request for 3.0.
See Bug 55354.
Reopening.
Eric, MvM, this bug best describes what we've just talked about regarding theme usability improvements. Randy, I don't suppose you have any free cycles to whip up a dialog that shows a color wheel as well as a list of system colors do you?
Nope, sorry. The system color name is as important as the color. There might be multiple blacks, grays, or whites. A dropdown combo with a color-swatch next to the name might work.
Yah, I'm not feeling really particular about the implementation. ;) You seem to have a good grasp of what would work in this scenario.
*** Bug 72705 has been marked as a duplicate of this bug. ***
Susan is now responsible for watching the [Themes] category.
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. If you have further information on the current state of the bug, please add it. 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.
