On Tue, 20 Aug 2024 23:53:45 GMT, Alisen Chung <ach...@openjdk.org> wrote:
>> Currently the bug described in the issue is that the colors of the >> TextComponents do not change when setting TextComponents to uneditable. The >> default uneditable color (SystemColor.control) happens to be the same as the >> default for the editable color for some L&Fs, so the fix may not be >> initially noticeable. However, the bug still exists where the the color is >> not being changed when changing between editable and uneditable. You can >> check by changing TextComponent.getBackground() code to return Color.GRAY on >> line 342 and you can see that TextComponents are not changing to a gray >> background when set to uneditable. >> >> This fix adds a private setBackground method in TextComponent so that >> TextArea and TextField can change the background color to the correct color >> (SystemColor.control) when set uneditable by overriding the TextComponent >> setEditable. You can verify the fix by changing this color to Color.GRAY and >> verifying the backgrounds change to gray when the TextComponents are >> disabled. > > Alisen Chung has updated the pull request incrementally with one additional > commit since the last revision: > > fix import Is it a bug? How do native text fields and areas behave on Linux and macOS? Does any of them change colours when it's switched into uneditable mode? AWT components should behave as native controls do. On Windows, uneditable text field and text area usually have a different background which corresponds to background of a dialog box. Is it the case on Linux and macOS? ------------- PR Comment: https://git.openjdk.org/jdk/pull/19876#issuecomment-2368341628
