Community
Participate
Working Groups
swt 20020918 1. Run the ControlExample 2. In the Button Tab 3. Change the Foreground color and the Background Color Notice that the button does not change. This works on Motif and GTK.
Platform behaviour. This has always been true.
*** Bug 44235 has been marked as a duplicate of this bug. ***
According to MSDN: http://msdn.microsoft.com/library/default.asp? url=/library/en-us/shellcc/platform/commctls/buttons/buttontypesandstyles.asp Apparently some buttons in windows allow for a change in the background color and some others don't. Specifically, only the ones of type "BS_OWNERDRAW" allow for that. As the name implies, the application has to draw the inside of the button, and that is what SWT does with arrow buttons but not with the other ones. So probably fixing the bug for arrow buttons would be relatively easy, while providing the same functionality for the rest of the SWT button types would require a bigger change in the code. Anyway that is not a crazy idea since this is what .net does with all buttons.
Reopening to assign to me.
WONTFIX
Workaround ????
There isn't one. The native Windows push button does not respect colors.
Yes there is a workaround using GC. I did this code a long time ago, but it was something like this: -------------------------------------------------- Color foreground = ((Button) getControl()).getForeground(); Color background = ((Button) getControl()).getBackground(); int x = 0; int y = 0; Rectangle rect = getControl().getBounds(); int width = rect.width; int height = rect.height; String text = ((Button) getControl()).getText(); if (width == 0) width = 1; if (height == 0) height = 1; ((Button) getControl()).setImage(new Image((getControl()).getParent().getDisplay(), width, height)); original = ((Button) getControl()).getImage(); GC gc; gc = new GC(original); gc.setForeground(foreground); gc.setBackground(background); gc.drawRectangle(x, y, width, height); gc.fillRectangle(x, y, width, height); Font font= ((Button) getControl()).getFont(); FontData fontData= font.getFontData()[0]; int fontSize = fontData.getHeight(); gc.setFont(((Button) getControl()).getFont()); int ximg = (x + width) / 2 - fontSize * text.length() / 3; int yimg = (y + height) / 2 - fontSize * 3 / 4; gc.drawText(text, ximg > 4 ? ximg : 4, yimg > 4 ? yimg : 4, SWT.DRAW_TRANSPARENT | SWT.DRAW_MNEMONIC); gc.dispose(); iDisable = new Image(((Button) getControl()).getParent().getDisplay(), original, SWT.IMAGE_DISABLE); if (!enabled) ((Button) getControl()).setImage(iDisable); -------------------------------------------------- Hope it helps. (In reply to comment #7) > There isn't one. The native Windows push button does not respect colors. >
*** Bug 476942 has been marked as a duplicate of this bug. ***
Reopening, AFAIK buttons in Windows can be themed these days.
(In reply to Lars Vogel from comment #10) > Reopening, AFAIK buttons in Windows can be themed these days. There are no quick fixes around to achieve this.. Not sure, if you are referring to Windows native widgets or .NET buttons(see comment 3) Because achieving this with native widgets is considered to be a lot work and requires entire widget to be custom drawn: https://bugs.eclipse.org/bugs/show_bug.cgi?id=407577#c3
I assigned the bug to me, because I prepared a first shot. I will commit that shortly. Luckily the winapi button control allows custom drawing, which means, that I don't have to draw the entire control myself, but I can hook into several drawing stages. Right now the only button (SWT) style, that uses owner-draw, is the ARROW button. I didn't changed anything there until now, because I'm not quite sure about the semantics of setBackground for that button style. As the button is transparent by default, it will have the background color of the underlying control. The same applies for the text part of the RADIO and CHECK button. For these two styles, the setBackground should better affect the symbol (square/circle) in front of the text, as these symbols now have a white background. Other remaining issues of the provided commit: - I can only test it on Windows 10. - Always a rectangle without rounded corners is drawn. I can remember, that until Windows 7 the buttons had a rounded corner? - The prefix is always drawn, not only after pressing the ALT key. - Toggle button has in activated mode only a slightly thicker border, as there is no API for setting two foreground colors.
New Gerrit change created: https://git.eclipse.org/r/70598
Created attachment 260939 [details] Test class for playing with different button styles and colors
Created attachment 261172 [details] Win7: Issues_with_Button_ForeGround_BackGround_Color_ControlExample (In reply to Eclipse Genie from comment #13) > New Gerrit change created: https://git.eclipse.org/r/70598 With my initial verification of this patch on Win7 with ControlExample.java, can notice below issues: With Fore-Ground color: 1. On applying a fore-ground color it doesn't goes well with Button's Image which become in-visible(issue seen with all 3 button types Push/Radio/Check), please refer attached screen-shot. With Back-Ground Color: 1. For a button with changed back-ground, look-n-feel doesn't changes on MouseEnter and MouseClick events. 2. On Clicking and pressing TAB out on colored button loses it's text.
(In reply to Niraj Modi from comment #15) > 1. On applying a fore-ground color it doesn't goes well with Button's Image > which become in-visible(issue seen with all 3 button types > Push/Radio/Check), please refer attached screen-shot. I totally forgot, that buttons can have an image. Now it's working. > With Back-Ground Color: > 1. For a button with changed back-ground, look-n-feel doesn't changes on > MouseEnter and MouseClick events. I decided, to put a new method in Control, to calculate a hover/selection color out of a given color. A similar method was already present in the Table widget, to hightlight the sort column. I think, we will need that method more often, if it comes to the fine-tuning of the dark theme. Alternative would be, to add a lot of API methods like setHoverBackground, setSelectedBackground ... > 2. On Clicking and pressing TAB out on colored button loses it's text. It's working. I had to intercept the WM_UPDATEUISTATE message with an additional check. See gerrit change. Remaining: SWT.RIGHT_TO_LEFT doesn't look good, if image and text is present.
(In reply to Conrad Groth from comment #16) > (In reply to Niraj Modi from comment #15) > > 1. On applying a fore-ground color it doesn't goes well with Button's Image > > which become in-visible(issue seen with all 3 button types > > Push/Radio/Check), please refer attached screen-shot. > > I totally forgot, that buttons can have an image. Now it's working. > > > With Back-Ground Color: > > 1. For a button with changed back-ground, look-n-feel doesn't changes on > > MouseEnter and MouseClick events. > > I decided, to put a new method in Control, to calculate a hover/selection > color out of a given color. A similar method was already present in the > Table widget, to hightlight the sort column. I think, we will need that > method more often, if it comes to the fine-tuning of the dark theme. > Alternative would be, to add a lot of API methods like setHoverBackground, > setSelectedBackground ... > > > 2. On Clicking and pressing TAB out on colored button loses it's text. > > It's working. I had to intercept the WM_UPDATEUISTATE message with an > additional check. See gerrit change. > > Remaining: SWT.RIGHT_TO_LEFT doesn't look good, if image and text is present. I am yet to verify/review the revised patch, since the fix came in late M7 time-frame. I thinks we should consider this fix for 4.6.1 or in early 4.7 if proposed API methods like setHoverBackground/setSelectedBackground are needed in Platform-UI.
Since this is not a regression and not critical functionality, this behavior change shouldn't be released to 4.6.1. It's also too late for 4.6. I quickly tested the patch on Windows 7, and it seems to work for PUSH buttons, but not for any of the other styles: - for TOGGLE, there is a hardly visible change of color, but it's way to subtle compared to native buttons whose background changes from gray to blue when selected - for CHECK, RADIO, and ARROW, the styling looks incomplete Calling button.setBackground(button.getBackground()) on a PUSH button makes the button feel like a Swing button, which goes against SWT principles: - background not blue on mouseover - blue border around focused and default buttons is less prominent - button looks flat, since it lost the reflection that gives it a 3d look - flat button looks odd next to a Combo or a checkbox that still has a 3d look (see e.g. Eclipse Preferences dialog) Javadoc of Control#setBackground(..) would need an update.
Created attachment 261254 [details] Windows 7
(In reply to Markus Keller from comment #18) > Since this is not a regression and not critical functionality, this behavior > change shouldn't be released to 4.6.1. It's also too late for 4.6. For 4.6 it is definitely too late. We might consider 4.6.1 if all the issues are resolved and it has been tested over a longer period of time.
(In reply to comment #18) > Since this is not a regression and not critical functionality, this behavior > change shouldn't be released to 4.6.1. It's also too late for 4.6. > > I quickly tested the patch on Windows 7, and it seems to work for PUSH buttons, > but not for any of the other styles: > - for TOGGLE, there is a hardly visible change of color, but it's way to subtle > compared to native buttons whose background changes from gray to blue when > selected > - for CHECK, RADIO, and ARROW, the styling looks incomplete > > Calling button.setBackground(button.getBackground()) Reality is that solid color background is long gone with all the gradients/animations/images used by system themes nowadays so overriding background (with solid color as getBackground returns) is guaranteed to screw things. The whole concept of background/foreground color needs a rethinking. > on a PUSH button makes the > button feel like a Swing button, which goes against SWT principles: > > - background not blue on mouseover > - blue border around focused and default buttons is less prominent > - button looks flat, since it lost the reflection that gives it a 3d look > - flat button looks odd next to a Combo or a checkbox that still has a 3d look > (see e.g. Eclipse Preferences dialog) > > Javadoc of Control#setBackground(..) would need an update.
Created attachment 262499 [details] Default theme for buttons and combos on Windows 10
(In reply to Markus Keller -- away till June 25 from comment #18) > Calling button.setBackground(button.getBackground()) on a PUSH button makes > the button feel like a Swing button, which goes against SWT principles: > > - background not blue on mouseover > - blue border around focused and default buttons is less prominent > - button looks flat, since it lost the reflection that gives it a 3d look > - flat button looks odd next to a Combo or a checkbox that still has a 3d > look (see e.g. Eclipse Preferences dialog) With the implemented interception of CUSTOM_DRAW callbacks from the OS, it is also possible to draw a gradient background or to place an image in the background. Nevertheless I would like to limit the scope of this issue to setting one background and/or foreground color. Someone, who wants to have a more native looking dark theme, has to use the theming capabilities of windows, but that affects all applications, not only eclipse. Since windows 8 MS changed the default appearance of their controls, e.g. buttons and combos already look flat nowadays by default. (see attached screenshot, which shows windows 10)
Buttons with image and text now behave like the default OS buttons. These buttons don't respect the text alignment, as do the styled buttons now. The ARROW button cannot be styled at all, because it's not really a button, but a section of a scrollbar and unfortunately scrollbars cannot be colored (see bug 491032). @Niraj: Can you review that patch please?
(In reply to Conrad Groth from comment #24) > Buttons with image and text now behave like the default OS buttons. These > buttons don't respect the text alignment, as do the styled buttons now. > > The ARROW button cannot be styled at all, because it's not really a button, > but a section of a scrollbar and unfortunately scrollbars cannot be colored > (see bug 491032). > > @Niraj: Can you review that patch please? Tested the patch on Win7 and can see the custom background coloring implemented by this patch is flat(3d effect is not persisted) and also confirm that 2d background coloring works fine for all buttons except ARROW. Quick question here: Can a similar background coloring be achieved in SWT client code as well by listening to paint event ?
(In reply to Niraj Modi from comment #25) > [...] > Quick question here: > Can a similar background coloring be achieved in SWT client code as well by > listening to paint event ? I don't fully understand your question, but I think the answer is: no. I created a button and registered a PaintListener. In that listener I'm painting a filled rectangle, but unfortunately that rectangle completely hides the button. I can also draw text on the given GC, but I have to calculate the position of the text similar to all the calculations I added to the Button class in my patch. And all the other stuff like hot/activated coloring, focus rectangle, image,... have to be drawn in the PaintListener. I didn't implement all of this, but I think at some point you will need private data of the Button which is not accessible from a PaintListener.
SWT team, can this be reviewed for M1? We have a customer which faces the decision to create his custom button implementation because of the missing feature to set the background color.
Thanks Conrad I tested this development and it looks already really good. I see one issue with the area you are drawing upon. I look to me as if you are overdrawing the outer border of the button while I think you should only draw in the inner part of the button. Screenshot https://imgur.com/CMTHFaH
Created attachment 263178 [details] Win10_Buttons_with_Background_Color See attached screen-shot for Win10 Buttons with background.
Created attachment 263179 [details] Win7_Buttons_with_Background_Color See attached screen-shot for Win7 Buttons with background.
Hi Conrad, GTK3 Buttons already have some native background color support, is it possible to have a similar custom implementation on Mac ? We also need to update the method JavaDoc for Control.setBackground(Color) which currently makes reference for Windows Buttons. Also from the behavior point of view, is there any way to address concerns raised by Markus comment 18 regarding the flat looks ? and also letting user know about this flat-behavior changes.
(In reply to Niraj Modi from comment #31) > is it possible to have a similar custom implementation on Mac ? This should be handled and discussed via a separate bug. > Also from the behavior point of view, is there any way to address concerns > raised by Markus comment 18 regarding the flat looks ? Actually this is desired (by our customers). If they set a background color, they do not want another gradient applied to the button which gives it a 3D lock.
Moving to M2.
(In reply to Niraj Modi from comment #33) > Moving to M2. Can this be reviewed for M2?
*** Bug 500720 has been marked as a duplicate of this bug. ***
(In reply to Lars Vogel from comment #34) > (In reply to Niraj Modi from comment #33) > > Moving to M2. > > Can this be reviewed for M2? There is no revised patch for addressing the remarks in comment 28 and comment 31.
(In reply to Lars Vogel from comment #28) > Thanks Conrad I tested this development and it looks already really good. > > I see one issue with the area you are drawing upon. I look to me as if you > are overdrawing the outer border of the button while I think you should only > draw in the inner part of the button. > > Screenshot https://imgur.com/CMTHFaH This is fixed with patch set 10 of https://git.eclipse.org/r/#/c/70598/
(In reply to Conrad Groth from comment #37) > (In reply to Lars Vogel from comment #28) > > Thanks Conrad I tested this development and it looks already really good. > > > > I see one issue with the area you are drawing upon. I look to me as if you > > are overdrawing the outer border of the button while I think you should only > > draw in the inner part of the button. > > > > Screenshot https://imgur.com/CMTHFaH > > This is fixed with patch set 10 of https://git.eclipse.org/r/#/c/70598/ The reason was: I used the background member of the Control class, which also caused other drawing operations, e.g. coloring the whole background area. This looked like if I were overdrawing the border of the button, but in fact these were two different drawing operations. Before my patch, setting a green background on a button would have drawn a green line around the button.
(In reply to Niraj Modi from comment #31) > Hi Conrad, > GTK3 Buttons already have some native background color support, is it > possible to have a similar custom implementation on Mac ? Sorry, I don't have any experience on a Mac. > We also need to update the method JavaDoc for Control.setBackground(Color) > which currently makes reference for Windows Buttons. Fixed with patch set 10 of https://git.eclipse.org/r/70598 > Also from the behavior point of view, is there any way to address concerns > raised by Markus comment 18 regarding the flat looks ? and also letting user > know about this flat-behavior changes. I will check that.
(In reply to Conrad Groth from comment #39) > > Also from the behavior point of view, is there any way to address concerns > > raised by Markus comment 18 regarding the flat looks ? and also letting user > > know about this flat-behavior changes. > I will check that. I added a hint in the Javadoc of the setBackground method. As already stated by Niraj, Windows native buttons already look flat since Windows 8. So the "only" affected versions are 7, Vista, XP... Because the windows API is very limited regarding custom coloring of controls, we have to do a lot of custom drawing. Before adding a lot more custom drawing, we should really think about using GTK (or any other framework) also for windows.
(In reply to Niraj Modi from comment #36) > There is no revised patch for addressing the remarks in comment 28 and > comment 31. AFAICS they have been addressed or clarified. Could you review and possible integrate into M2?
(In reply to Lars Vogel from comment #41) > (In reply to Niraj Modi from comment #36) > > > There is no revised patch for addressing the remarks in comment 28 and > > comment 31. > > AFAICS they have been addressed or clarified. Could you review and possible > integrate into M2? Looks less likely for M2, as latest patch is failing with ControlExample on Win7 giving IllegalArgumentException. Once above problem is resolved we should consider adding JUnits tests for Button's setBackground/getBackground methods with non-default color values and these tests runs can be limited to Windows only.
(In reply to Niraj Modi from comment #42) > Once above problem is resolved we should consider adding JUnits tests for > Button's setBackground/getBackground methods with non-default color values > and these tests runs can be limited to Windows only. I suggest to open a new bug for the new / updated tests. Note: IIRC Linux also supports setting the background. Maybe we have tests already, limited to Linux?
(In reply to Niraj Modi from comment #42) > (In reply to Lars Vogel from comment #41) > > (In reply to Niraj Modi from comment #36) > > > > > There is no revised patch for addressing the remarks in comment 28 and > > > comment 31. > > > > AFAICS they have been addressed or clarified. Could you review and possible > > integrate into M2? > Looks less likely for M2, as latest patch is failing with ControlExample on > Win7 giving IllegalArgumentException. > Once above problem is resolved we should consider adding JUnits tests for > Button's setBackground/getBackground methods with non-default color values > and these tests runs can be limited to Windows only. I fixed the IllegalArgumentException. It was the getBackground method in the Button class, which returned an invalid color, if no custom background color was set before.
(In reply to Lars Vogel from comment #43) > (In reply to Niraj Modi from comment #42) > > Once above problem is resolved we should consider adding JUnits tests for > > Button's setBackground/getBackground methods with non-default color values > > and these tests runs can be limited to Windows only. > > I suggest to open a new bug for the new / updated tests. > > Note: IIRC Linux also supports setting the background. Maybe we have tests > already, limited to Linux? The class org.eclipse.swt.tests.junit.Test_org_eclipse_swt_widgets_Control already contains a test method test_setBackgroundLorg_eclipse_swt_graphics_Color(). The class Test_org_eclipse_swt_widgets_Button extends Test_org_eclipse_swt_widgets_Control, so the changed code is already covered.
(In reply to Conrad Groth from comment #44) > I fixed the IllegalArgumentException. It was the getBackground method in the > Button class, which returned an invalid color, if no custom background color > was set before. Niraj, any further concerns with the patch?
(In reply to Lars Vogel from comment #46) > (In reply to Conrad Groth from comment #44) > > > I fixed the IllegalArgumentException. It was the getBackground method in the > > Button class, which returned an invalid color, if no custom background color > > was set before. > > Niraj, any further concerns with the patch? Have verified the latest patch and till now all looks good. Will take a final call on this shortly.
(In reply to Niraj Modi from comment #47) > Have verified the latest patch and till now all looks good. > Will take a final call on this shortly. Thanks. This will help to improve the dark theme on Windows quite a bit.
(In reply to Niraj Modi from comment #47) > Have verified the latest patch and till now all looks good. > Will take a final call on this shortly. Any news on this Niraj?
(In reply to Lars Vogel from comment #49) > (In reply to Niraj Modi from comment #47) > > Have verified the latest patch and till now all looks good. > > Will take a final call on this shortly. > > Any news on this Niraj? On my plan for this week, waiting for this week's I-Build to pass.
(In reply to Niraj Modi from comment #50) > On my plan for this week, waiting for this week's I-Build to pass. After lot of trouble, I-Build finally worked.
Gerrit change https://git.eclipse.org/r/70598 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=0822f2030fcfc1ca7d2cdb69aae86e45e1c85556
Thanks Conrad for this awesome development and Niraj for the review. Conrad, can you add an entry to the N&N M3? https://git.eclipse.org/r/#/admin/projects/www.eclipse.org/eclipse/news
(In reply to Eclipse Genie from comment #52) > Gerrit change https://git.eclipse.org/r/70598 was merged to [master]. > Commit: > http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/ > ?id=0822f2030fcfc1ca7d2cdb69aae86e45e1c85556 There were a few 32-bit compilation errors after this commit, fixed them via http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=443a965a75a5aa7579e805c7a34ecbdf72594941
Raised bug 505835 to investigate similar(custom paint operation) approach for MAC's Button.
This fix caused regression (at least on Windows 10), see bug 506371.
Verified fix in Build id: I20161024-2000 on Win7
FormToolkit.createButton() ends up setting the background for buttons, so with this change buttons created by FormToolkit look different. Is there any thought that FormToolkit should be changed?
