RFR: 8075917: The regression-swing case failed as the text on label is not painted red with the GTK L&F [v5]

[Abhishek Kumar]

On Tue, 26 Mar 2024 08:22:52 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> @aivanov-jdk 
>> 
>>> This looks weird… So you're saying Label[Enabled].textForeground and Label[Disabled].textForeground are used for Nimbus (and Synth and GTK) instead of Label.foreground and Label.disabledForeground which are used for other L&Fs.
>> 
>> As per my understanding, Yes, for Nimbus LAF the UI properties are different than other LAF.
>> 
>>> Shouldn't we fix the problem by correcting the keys instead? It looks like it's what you're doing for specific components.
>> 
>> I am not sure if it is a problem or nimbus LAF is supposed to be like this.
>> 
>>> Is it specified anywhere that Synth-based L&Fs use different constants? It results in incorrect colors.
>> 
>> Need to check on this.
>> 
>>> If a developer sets the common properties, should they override Look-and-Feel defaults?
>> 
>> Will check and revert back.
>
>> @aivanov-jdk
>> 
>> > This looks weird… So you're saying Label[Enabled].textForeground and Label[Disabled].textForeground are used for Nimbus (and Synth and GTK) instead of Label.foreground and Label.disabledForeground which are used for other L&Fs.
>> 
>> As per my understanding, Yes, for Nimbus LAF the UI properties are different than other LAF.
>> 
>> > Shouldn't we fix the problem by correcting the keys instead? It looks like it's what you're doing for specific components.
>> 
>> I am not sure if it is a problem or nimbus LAF is supposed to be like this.
>> 
>> > Is it specified anywhere that Synth-based L&Fs use different constants? It results in incorrect colors.
>> 
>> Need to check on this.
>> 
>> > If a developer sets the common properties, should they override Look-and-Feel defaults?
>> 
>> Will check and revert back.
> 
> 
> As I understood, what `Label.background` color to be set, is determined via **`Nimbus.Overrides`** property
> i.e.,  if `Label.background` is set to `Nimbus.Overrides`,  it should override the `label.setBackground()` user color setting 
> else 
> if `Nimbus.Overrides` is not set or set to null, then `Label.setBackground()` will hold precedent even if `Label.background` property is set
> 
> 
> Similarly, if `Nimbus.Overrides` is set with `Label.background` color **AND** Label[Enabled].background is also set,
> then 
> Label[Enabled].background will have priority over 
> Label.background which will have priority over
> Label.setBackground() 
> 
> but this is also controlled by another boolean property **`Nimbus.Overrides.InheritDefaults`** in way that the above precedence is valid only if if Nimbus.Overrides.InheritDefaults is true
> 
> if **`Nimbus.Overrides.InheritDefaults`** is false, then Label[Enabled].background will be ignored
> and
> Label.background will have priority over 
> Label.setBackground() 
> 
> This is somewhat explained in `https://docs.oracle.com/en/java/javase/21/docs/api/java.desktop/javax/swing/plaf/nimbus/package-summary.html` and tested in` test/jdk/javax/swing/plaf/nimbus/ColorCustomizationTest.java` so in a way, it seems widget[state].color setting is applicable for Nimbus only since we dont have GTK.Overrides property

@prsadhuk I have updated the PR to skip the GTK L&F for both the test bug as we discussed that GTK L&F may not support the color setting by UIManager. As per the documentation for UIManager https://docs.oracle.com/en/java/javase/21/docs/api/java.desktop/javax/swing/UIManager.html, it states that `The set of defaults a particular look and feel supports is defined and documented by that look and feel. In addition, each look and feel, or ComponentUI provided by a look and feel, may access the defaults at different times in their life cycle. Some look and feels may aggressively look up defaults, so that changing a default may not have an effect after installing the look and feel. Other look and feels may lazily access defaults so that a change to the defaults may effect an existing look and feel. Finally, other look and feels might not configure themselves from the defaults table in any way. None-the-less it is usually the case that a look and feel expects certain defaults, so that in ge
 neral a ComponentUI provided by one look and feel will not work with another look and feel`.

So, it seems the UIManager color setting may not be honored in GTK L&F.

Please have a look on the updated changes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17763#issuecomment-2114569799