As Substance look-and-feel nears the official release 4.1 (scheduled for November 12th), i’m working on the missing documentation. This entry talks about the painter layer in Substance.

Painter encapsulates a common painting logic. For example, in Substance, selected elements in lists, tables, trees and menus are painted with the same gradients. So, instead of replicating this code across different UI delegates, it is extracted into a common painter. In addition to code reuse, it:

• Makes it easier to tweak an existing painting sequence.
• Lets applications to specify a custom (branding) painter which is applied to all relevant controls.
• Lets applications and third-party developers to provide consistent appearance of custom components without locking themselves to internal implementation details of Substance.

Currently, Substance uses three types of painters which are used on different types of controls and window areas. The core binary bundles a number of painter implementations which are available as externally supported APIs. In addition, Substance provides a plugin layer that allows applications to specify custom painter implementations which are used at runtime to paint existing core and third-party components.

Existing painter types

Currently, Substance uses three different types of painters. These are:

• Gradient painters
• Title / header painters
• Border painters

The vasy majority of Substance visuals are painted by using these three painter types (applying the current watermark if necessary). The links above provide more technical information on how to specify custom painters and how to use them to paint custom components and window areas. Applications that wish to provide consistent appearance under different Substance skins are strongly encouraged to use the current runtime painters, even if it results in tying the application code to Substance.