On Tue, 26 Mar 2024 08:22:52 GMT, Prasanta Sadhukhan <[email protected]> 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
