Community
Participate
Working Groups
Build Identifier: 3.7M7 (Cocoa, x86_64) If I try to change background color of text field when the focus is set on it, the background color would't changed (just a subpixel-width frame will occur). But the field stores new color and it is set right after focus will set on another field. Foreground color changes normally in the same way. I'll tried to use update(), redraw(), etc, but these functions has no effect regarding this bug. Reproducible: Always
P.S. The same code works fine on Windows.
I confirm this is still an issue while changing the background color of the Text widget while it has focus. My use case is validation while typing. A narrow color change does occur at the top of the control, which leads me to believed the control is repainted after the color is changed and seems to be connected to the height of the i-beam. I wrapped the color change into a thread with a 1 second delay, but still have the same problem. Calling update and/or redraw has no effect. The only workaround I have found is to lose focus: text.setEnabled(false); // lose focus text.setBackground(colorWrite); text.setEnabled(true); text.setFocus(); It happens on OSX running java 1.7.45. org.eclipse.swt.cocoa.macosx.x86_64 (3.103.0.v20131212-1946) "Standard Widget Toolkit for Mac OS X (Cocoa)" [Resolved] org.eclipse.swt (3.103.0.v20131212-1937) "Standard Widget Toolkit" [Resolved]
This is my workaround. Fortunately the cursor position is not affected as I type in the box and the focus is removed/restored. // BUG OSX will not repaint background if it has focus static protected void setBackground(Text text, Color color) { if (text.isFocusControl() && System.getProperty("os.name").toLowerCase().contains("mac")) { text.setEnabled(false); text.setBackground(color); text.setEnabled(true); text.setFocus(); } else { text.setBackground(color); } }
I vote for this defect because Steven's workaround cannot be used when validating input from TextCellEditor: disabling/focus close editor.
This is the exact reason why eclipse is dead as IDE, a bug from 2011 that can be reproduced even today with SWT 3.111.0.v20190605-1801 with the last version of MacOS. And after 8 years it is in status NEW, not even CONFIRMED! Maybe in 20 years we will get nuclear fusion or flying cars, I hope that we will get also this bug fixed, but I would not bet on it.
(In reply to Marco Orlandin from comment #5) This is the wrong place to rant about Open Source development. If you want to get it fixed: provide a unit test, a patch, get a contributor to work on it or just wait. But when you just wait, don't expect that someone works on it for you, as priorities are different. This is a very lively project with smart and engaged people that provide and we continuously improve the IDE as fast as we can.
(in response to Karsten Thoms) The priorities could be different, but we are talking of a bug of 9 years ago, reported by multiple people and fairly easy to reproduce. Also this is not a rant about OS development, it is just astonishment for a bug in NEW status after 9 years. At this point you could change the status in to Wont't fix
Whether the bug will be closed as WONTFIX can be decided later. This is why it was marked as stale bug, and if noone works on it it would be closed as WONTFIX after some period. You decided to remove the stalebug marker. The procedure might be different for other projects, but the initial status is NEW here until someone is really starting to work on it. Then it gets ASSIGNED. The Platform team is fixing over 2000 issues each year, and there are plenty that don't get enough attention. Sorry for being this one of that. 9 years sounds long, but this project is over 20 years long and is mostly staffed with volunteers. There are so many requests open, and this is just a very minor thing which I myself did not ever recognise as disturbing. If it would be my work to solve that issue, it would happen immediately. Otherwise, we need contributors and more committers that truly understand OS work. To accelerate this you could provide a test case that makes this reproducible.
Actually, I can't reproduce it. If I add a FocusListener to a Text field and set its background on focus gain, this happens. This code will create 2 Text fields and set the focus on the 2nd after 3 seconds. The background becomes gray as expected. If you click on one of the text fields, it will change the background. So where is the problem? Screencast: https://share.getcloudapp.com/WnuEz2mJ Display display = new Display (); final Shell shell = new Shell (display); shell.setLayout(new FillLayout()); Text text1 = new Text(shell, SWT.SINGLE | SWT.BORDER); Text text2 = new Text(shell, SWT.SINGLE | SWT.BORDER); Color gray = text1.getDisplay().getSystemColor(SWT.COLOR_DARK_GRAY); shell.open (); Color origBG = text2.getBackground(); FocusListener focusListener = new FocusListener() { @Override public void focusLost(FocusEvent e) { ((Text)e.widget).setBackground(origBG); } @Override public void focusGained(FocusEvent e) { ((Text)e.widget).setBackground(gray); } }; text1.addFocusListener(focusListener); text2.addFocusListener(focusListener); Executors.newScheduledThreadPool(1).schedule(() -> display.syncExec(()->text2.setFocus()), 3, TimeUnit.SECONDS); while (!shell.isDisposed ()) { if (!display.readAndDispatch ()) display.sleep (); } gray.dispose(); display.dispose ();
This is exactly the place to rant about it. I spent much time finding a workaround, and then took the time to report on the issue. Even if I submitted a patch, it would have most likely sat around for years under debate. Eclipse has a very disappointing culture as pointed out by Karsten, and something should be done to address it. Concerning this issue specifically, if you can't reproduce it, close it. It should have been tended to years ago. Your committers need to OWN their project....
I change my last comment to read 'Marco', not 'Karsten'.
(In reply to Steven Spungin from comment #10) > This is exactly the place to rant about it. I spent much time finding a > workaround, and then took the time to report on the issue. Even if I > submitted a patch, it would have most likely sat around for years under > debate. Please try to submit patch first, and after that you can continue to rant. > Eclipse has a very disappointing culture as pointed out by Karsten, and > something should be done to address it. Fully agree, with the second part. For example, you could try to start contributing to the project: https://wiki.eclipse.org/Platform/How_to_Contribute > Your committers need to OWN their project.... It might be surprising, but we own *our* projects, and for *my* project this issue is absolutely, totally irrelevant. So should I spent my time to fix it? Answer is obvious. In general, Eclipse is not just SWT Mac port, so this specific issue has a very small target group. Beside this, many of our projects has no relationship at all to Mac environment, most of us even don't own any Mac's. So while contributing to Eclipse I personally ignore all Mac specific issues, because even if I would have a patch, I would not be able to verify that. So what does it mean for you as a Mac user? Instead of complaining, if you want change something in Eclipse, start to do something concrete. E.g. (ask your manager to) spend more money to Eclipse foundation so that we can hire more people dedicated to the Mac port, etc.
My point was just proven. Take a look at my commit history fools.
(In reply to Steven Spungin from comment #14) > My point was just proven. Take a look at my commit history fools. Do you really think you will get any success with such comments?
Please just close the bug if you are not going to follow up on it. Just getting a response telling me I am a moron is success in itself, if that is what it takes to bump this issue.
Changes for Bug 262784 fix this as well.
