Exposing Theme Metadata
All available UI Customization Keys that can be used in Custom Themes must be defined in a dedicated *.themeMetadata.json file which is registered via
com.intellij.themeMetadataProvider extension point.
The following minimal sample demonstrates all details required when exposing UI customization keys of your plugin's UI.
name- Human-readable name, e.g., plugin name
fixed- Specifies whether metadata describes external elements, e.g., an UI library. Default:
ui- Root element listing all customization keys:
key- Customization key name (see Key Naming Scheme)
description- Description to be shown to Theme authors editing *.theme.json files
truewhen the key is deprecated. It is highly recommended to provide explanation and/or replacement in
source- Fully qualified name of the underlying UI component implementation, e.g.,
since- The release number when this UI customization key was exposed, e.g.,
sinceattribute is supported starting with the 2019.2 release and it is not displayed in versions prior to 2019.2.
Color keys can be used via
JBColor.namedColor() providing defaults for Light and Dark theme:
Other keys can be obtained via
Key Naming Scheme
All keys must follow this Naming Pattern:
Background color for objects with text.
Objects with a single color (do not have foreground/background). Do not use the word "Color" separately, always use with the "part" word.
Enabled components, default state. Omit this word. The default state does not need explicit naming.
Enabled components that might be perceived as interactive but are actually not. Example: a tree with visible selection but not in focus. Goes after other state words.
The current focused component.
A selected tab or any other control that has equally meaningful selected and inactive states.
An action as indicated in states.
Validation states. See example in the guide article.
A part is an internal element of a component, e.g., an arrow button in a combo box. Create a separate key for a part if its properties differ from the parent object.
If a part is common among several components, use the same name for it. Notable examples of common parts:
A line around a component.
The vertical line that denotes typing place.
An object that has been modified but not yet saved.
Wide focus border around a component.
Secondary labels with additional useful information. Usually appear in gray color to the right or below a regular label.
An icon that is created with a source code (not an image file).
The focus place in a component with selectable text. Can be in a typed text or in a list or tree.
A horizontal or vertical line inside a component. Can be with a label.
A shadow below a component.
Use a subobject when creating keys for one of the following:
An implementation variation. Usually has a similar set of UI property keys as the parent object. Examples:
Tool window notification:
An internal smaller component of a complex component with its own UI and behavior. Examples:
Tool window tab:
The hint text at the bottom of a popup:
If a component has a gradient color, add the words "start" and "end" for the beginning and ending of a gradient. Examples:
Capitalize Object and SubObject. Use lowerCamelCase for property.
Do Not Use
Do not use
Some color keys are not named according to the rules above. Such keys are inherited from Java Swing and cannot be renamed for compatibility reasons. Do not use naming patterns from the legacy keys.
Examples of Swing keys:
IntelliJ Platform Metadata
Metadata is split up as follows:
IntelliJPlatform.themeMetadata.json- all keys from IntelliJ Platform and custom UI components
JDK.themeMetadata.json- all keys from Swing components
New keys should be added to IntelliJPlatform.themeMetadata.json only (or corresponding "local" *.themeMetadata.json file of the plugin if applicable).