Community
Participate
Working Groups
Build F2 (20020602) Win2K If you switch windows color scheme after you started eclipse, then Eclipse hangs on to some of the old colors for certain things. Examples of this are background colors for view icons like the 'X' to close the view, and the gradient color of the title bar for a view. - Go to display properties in windows -> Appearance. - Set your scheme to "Maple" - Open Eclipse - Set your scheme to "Slate" - Go back to Eclipse - Focus on one of the views Notice how the views still use colors from the old scheme.
Related to PR# 19218
You currently need to restart to get the new settings. Need SWT support for this.
Toolbar button background colours also do not update properly.
*** Bug 19218 has been marked as a duplicate of this bug. ***
Post R2.0.
Viki, how far did we get with this one? I seem to remember that we fixed all the places in SWT but needed to change Eclipse.
New API is needed for the gradient stuff on CLabel and CTabFolder. I believe that is the only outstanding thing.
Was there not a simple change that would let them get it "for free"? Let's get them to do it rather than adding API.
The SWT.Settings callback can be used to change any hard coded gradients that Eclipse has set for CTabFolder and CLabel.
I assume the roadblock was that platform UI couldn't listen for changes to system colors. If we can do that now then we can consider fixing this.
*** Bug 50361 has been marked as a duplicate of this bug. ***
Created attachment 81755 [details] Patch implementing color update due to system change This patch hooks the SWT callback notifying of system changes. It then rereads the themes and updates the color registries. If this code looks good, I figure out the corresponding changes for fonts.
Created attachment 84278 [details] Updated test case to match last-wins for color defs Update to the test suites to match the new behaviour. The code patch made it so new colour definitions would override existing ones (previously they were ignored). The ThemesTestSuite checked for this by attempting to define the same colors (swtcolor and rgbcolor) twice, checking that the resulting value matched the first definition. The test has been changed to verify that it matches the last definition. One subtle change is that previously the 2nd definition was a bogus/invalid value, now it must be a legal value (I chose COLOR_RED) for the test to make sense.
I think this looks ok.
Released to HEAD, fixed in I20071203-0800. Will open a different bug for corresponding font updating.
Verified in M4. I've opened a new bug #19229 for the font specific work
(In reply to comment #16) > I've opened a new bug #19229 for the font specific work Sorry that should be bug #213595.
(cleaning up "My Requests" query)
I don't know if these changes are still relevant but are causing issues on Linux because of a fix for the bug 563001. The code in question is the method "updateThemes". See the bug 563001, comment 8 for details.
