LookAndFeel-независимая ссылка цветовых клавиш

Question

В настоящее время я работаю над набором пользовательских элементов управления для продукта компании, в которой я работаю. Для этого я расширяю множество элементов управления Swing, а также переопределяю множество paint методов.

Чтобы поддерживать согласованную цветовую схему, я получаю цвета для моих paint, setBackground и др. Методов, используя UIManager.getColor.

Это было прекрасно, пока мы не заметили, что Nimbus LookAndFeel, который поставляется с текущими версиями JRE, использует совершенно разные цветовые клавиши, поэтому многие вещи выглядят совершенно неуместно.

Например, в то время как все остальные стоковые LookAndFeels (Metal, Windows Classic,Windows, CDE / Motif, GTK) определили ключ «текст» как яркий фон для текстов и «textText» как соответствующий цвет переднего плана, «текст» в Nimbus на самом деле является черным цветом переднего плана, а стандартный цвет фона текста, по-видимому, не существует.

"TextField.background" будет работать, но это для инстаКроме того, не существует для Windows LookAndFeels.

Полагаю, вы уже столкнулись с проблемой.Я не хочу поддерживать набор цветовых клавиш для каждого LAF, который знает, какие LAF будут добавлены в будущем и которые моя компания может решить использовать.

Простым решением было бы избавитьсяNimbus, конечно, но по понятным причинам моему боссу вообще не нравится эта идея, кроме того, Nimbus является частью JRE в наши дни и должна быть поддержана.

Поэтому мне интересно, есть ли какая-либо стандартизированный способ получения LAF-зависимых цветов, например, «текстовый фон / передний план», «выделенный текст bg / fg» и т. Д .?

Answer 1

Да, как и подразумевал @josefx, к сожалению, это не так, как работают пользовательские интерфейсы. Это не пул общих переносимых свойств, а набор реальных компонентов и конкретных реализаций для каждого из этих компонентов. На самом деле это не расширяемая система, удобная для пользовательских компонентов.

Уровень абстракции является компонентом, а не чем-то более мелким. Если вы попытаетесь запросить ComponentUI для компонента, о котором L & F не знает, вам не повезло. И ComponentUI - это всего лишь оболочка для метода рисования, поэтому он вообще не обязан предоставлять какие-либо метаданные.

Проще говоря, вы застряли, в основном, применяя технику «цветовой чистки» JTextField (или некоторого другого соответствующего компонента), которую предлагает josefx, или добавляя конкретную поддержку в свой код для обработки эксцентриситетов имен свойств L & F, которые вы желаю хорошо поддержать.

Другое предложение заключается в том, чтобы «упредить» изменение L & F и создать подкласс L & F, которые вы хотите поддерживать, чтобы сделать ваши компоненты более первоклассными гражданами в этих L & F. Когда L & F изменится на L & F, который вы поддерживаете, молча поменяйте имя их класса именем вашего подкласса, а затем реализуйте ComponentUI для ваших пользовательских компонентов и расширьте родительский метод LookAndFeel.createUI, чтобы он «знал» о ваших новых компонентах .

Ничто из этого не красиво, но система компонентов Swing не предназначена для расширения во время выполнения для обработки пользовательских компонентов. Весь набор компонентов выполняется одновременно с созданием L & F.

Answer 2

Я не уверен, что существует "стандартизированный" способ получения этих значений.

Как вы заметили, Nimbus использует своих собственных имен для цветов.В частности, свойства textForeground и textBackground.

Эта странность вероятна потому, что Nimbus использует небольшой выбор основных цветов (указан как Основной в на диаграмме ), для которых рассчитаны вторичные цвета, которые, в свою очередь, используются в качестве основы для всех оставшихся цветов.

Answer 3

Обойти это невозможно - вам нужно создать собственный слой абстракции для имен цветов (и, возможно, других имен свойств).

В основном у вас есть стоковые LookAndFeels (Metal, Windows Classic, Windows, CDE / Motif, GTK), которые используют свои собственные названия цветов, и Nimbus, который использует разные имена.

Создать класс, например LafProperties чтобы у каждого свойства / цвета был свой метод (например, «getTextColor»). Этот класс возвращает свойства для классических стилей Laf. Затем расширьте этот класс для Nimbus и измените только методы, которые отличаются от Nimbus.

Если у стандартных Lafs и Nimbus большинство свойств имеют разные имена, то при использовании вы можете использовать интерфейс и два реализующих класса.

Answer 4

Не очень хороший способ, но он должен работать по основам:

1. Создать JTextField
2. вызвать getForeground, getBackground, getSelectionColor для получения зависимых от laf значений

Обновление:

Класс ComponentUI и его подклассы, которые являются базовыми классами для всех типов, предоставляют только метод для инициализации зависимых от laf значений по умолчанию, они не предоставляют прямойспособ доступа к этим значениям.

Answer 5

Несколько вещей всплывают у меня в голове, когда я читаю твой вопрос, который немного приправлен разочарованием в животе, если я хорошо почувствовал:

• зависимость от стандартов / поддержки JRE и решений по обеспечению независимости / свободы
• стандарты и соответствие творчеству и индивидуализации

И, таким образом, в конечном итоге:

• практический подход вашего босса против программистов, понимание дальнего будущего

Answer 6

Класс java.awt.SystemColor предоставляет переменные для множества общих атрибутов.

Для текста переднего плана / фона используйте поля-члены text / textText;для выделенного текста используйте textHighlight / textHighlightText.