… or using juce::LookAndFeel for its intended purpose.
I’ve generally avoided using JUCE’s LookAndFeel classes unless its super convenient. I think it looks nicer to paint your own custom components your own way. LookAndFeel definitely has its place, but in my workflow I don’t find them particularly useful. That being said I did use them in PFT in a way I was surprised by.
JUCE’s LookAndFeel system lets you map colourIds (int) to juce::Colours – any int, any juce::Colour. You’re totally allowed to push your own stuff in there. Nothing restricts you to just the predefined component customization colourIds. This isn’t profound. It’s exactly what LookAndFeel was intended to be used for I just never thought to use it this way.
In PFT, the filter editor and the modulator editor each have their own color palette. This is controlled in each by setting colourIds in LookAndFeel. The paint method for child components looks up colors using an enum class (I like this more than just using an int). This simplifies the painting process and lets me paint every single component as if it adheres to one single color scheme.
If you’re careful with it you could probably also pack arbitrary data into the bits of the juce::Colour. Probably (definitely) avoid pointers and stuff like that but for other POD like UI flags its a nice place to put them that propagates throughout your entire application.
Ps.
I named my color lookup wrapper ColourScheme. Don’t do that unless you want to have to escape to the global namespace every time you want to use it from within a class that inherits from LookAndFeel.