我目前正在为我正在工作的公司的产品开发一组自定义控件。为此，我扩展了许多Swing控件并覆盖了很多paint方法。< / p>
为了保持一致的配色方案，我会使用paint收到setBackground，UIManager.getColor等方法的颜色。
在我们注意到当前JRE版本附带的 Nimbus LookAndFeel使用完全不同的颜色键时，这是非常好的，因此很多东西看起来完全不合适。
例如，所有其他股票LookAndFeels（金属，Windows经典，Windows，CDE / Motif，GTK）已将关键“text”定义为文本的明亮背景和“ textText“作为相应的前景色，Nimbus中的”text“实际上是黑色前景色，标准文本背景色似乎不存在。
“TextField.background”可以使用，但是，例如，Windows LookAndFeels不存在。
我想你现在已经解决了这个问题。我不想为每个LAF维护一组颜色键，谁知道将来会添加哪些LAF以及我公司可能决定使用哪些颜色键。
当然，一个简单的解决方案是摆脱Nimbus，但可以理解的是我的老板根本不喜欢这个想法，除了Nimbus现在是JRE的一部分，应该得到支持。
所以我想知道是否有任何标准化的方法来获得与LAF相关的颜色，比如“文本背景/前景”，“选择文本bg / fg”等等。
答案 0 :(得分：3)
我不确定是否有“标准化”的方式来获取这些值。
正如您所注意到的，Nimbus使用its own names来表示颜色。具体而言，属性textForeground和textBackground。
这种奇怪之处可能是因为Nimbus uses a small selection of basic colors（在the chart中列为主要版本），它们具有从它们计算的辅助颜色，而这些颜色又用作所有剩余颜色的基础。
答案 1 :(得分：3)
是的，正如@josefx暗示的那样，遗憾的是这不是UI的工作方式。它们不是通用便携式属性池，而是它们是一组实际组件以及每个组件的特定实现。它不是一个对自定义组件友好的可扩展系统。
抽象级别是组件，而不是更精细的组件。如果你试图为L＆amp; F不知道的组件要求ComponentUI，那你就不走运了。而ComponentUI只不过是一个paint方法的包装器，所以它没有义务公开任何元数据。
简单地说，你基本上没有使用josefx建议的JTextField（或其他一些适当的组件）“颜色刮擦”技术，或者在你的代码中添加特定的支持来处理L＆amp; F的属性名称的怪癖。你希望得到很好的支持。
另一个建议是“先发制人”L＆amp; F的变化，并将你希望支持的L＆amp; Fs子类化，使你的组成部分更多地成为那些L＆amp; Fs中的头等公民。当L＆amp; F更改为您支持的L＆amp; F时，使用您的子类类名静默地切换其类名，然后为您的自定义组件实现ComponentUI，并扩展父LookAndFeel.createUI方法以使其“知道”关于你的新组件。
这些都不是很好，但是Swing组件系统并不是设计为在运行时可以扩展来处理自定义组件。当创建L＆amp; F时，整个组件套件都会立即完成。
答案 2 :(得分：2)
不是一个好方法，但它应该适用于基础：
更新：
作为所有外观的基类的ComponentUI类及其子类仅提供初始化依赖于laf的默认值的方法，它们不提供访问这些值的直接方法。
答案 3 :(得分：2)
没有办法绕过它 - 你必须为颜色名称（以及可能的其他属性名称）创建自己的抽象层。
基本上你有使用自己的颜色名称和使用不同名称的Nimbus的LookAndFeels（金属，Windows经典，Windows，CDE / Motif，GTK）库存。
创建一个类，例如LafProperties以便为每个属性/颜色提供方法（例如“getTextColor”）。此类返回经典Laf样式的属性。然后为Nimbus扩展此类，并仅更改Nimbus中不同的方法。
如果库存Lafs和Nimbus的大多数属性命名不同，那么使用它可能会使用一个接口和两个实现类。
答案 4 :(得分：0)
java.awt.SystemColor类为许多常见属性提供变量。
对于文本前景/背景，请使用成员字段text / textText;对于所选文字，请使用textHighlight / textHighlightText。
答案 5 :(得分：0)
在我的脑海里写下你的问题几乎没有什么东西，如果我感觉良好的话，这有点令人沮丧：＃/ p>
最终：