Read-only (non-editable) JTextArea – background color not updated

[stanio]

Not sure if this could be considered a bug as I'm seeing such behavior with at least one other L&F – Nimbus:

The background color of non-editable text-area doesn't seem to reflect the actual background color used.

        JTextArea textArea = new JTextArea();
        textArea.getBackground(); // editable background
        textArea.setEditable(false);
        textArea.getBackground(); // non-editable background

Using FlatLaf 0.38.

[DevCharly]

The reason for this is a "temporary" workaround in Swing:

https://github.com/openjdk/jdk/blob/1f5e21a16e1bb9a7291b38cedf4269717bbbe428/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTextUI.java#L228-L239

[stanio]

Thanks for the explanation and I'm closing this.

[stanio]

It's funny though, the JGoodies Plastic L&F seems to have the background color of read-only text-area updated.

[DevCharly]

Yes, there is some code in PlasticTextAreaUI that does basically the same as in BasicTextUI.updateBackground() to update the background color.

Do you think FlatLaf should do the same?

I wonder how did you discover this inconsistency?

[stanio]

I don't think FlatLaf should go the extra mile if there's no enough demand for it. I've discovered it while looking into:

• https://sourceforge.net/p/squirrel-sql/git/merge-requests/61/

which is not text-area related, but text-pane. I've just compiled small sample to compare the L&F of standard text components.

[DevCharly]

Has reviewed all text component UI delegates. Background painting in FlatTextAreaUI was very different to what is done in other text component UI delegates. So to unify text component background painting and to have consistent behavior of background color across all text components, FlatTextAreaUI now updates the background color property if enabled or editable state changes in the same way as Swing does it for all other text components.

[stanio]

Thank you for the extra effort!