gfx/lookandfeel.h
LookAndFeel: where a widget's appearance lives, separately from what it does.
#include <sonore/gfx/lookandfeel.h>- 2types
- Guides: The native editor
On this page
Design notes
Why the split is worth a virtual call
A Slider knows how a drag becomes a value. It should not know what a knob looks like, because those two change for completely different reasons: the drag behaviour is decided once and is the same in every plugin ever made, while the appearance is the thing a generated plugin most wants to be its own.
Keeping them apart means a plugin can supply a LookAndFeel and get its own face without touching -- or being able to break -- the interaction. Which matters here more than in a hand-written framework: the appearance is the part a model writes, and the part most likely to be wrong.
The defaults are meant to be shipped, not replaced
A generated plugin whose author says nothing about appearance gets this, and it has to look deliberate. A default that looked like a placeholder would mean every plugin needed a designer before it could be released.
Types 2
Every state a widget can be in when it is drawn. Passed as one struct so adding a state later does not change six signatures.
How every widget is drawn: a palette and a virtual draw call per kind of control. Mirrors the reference's LookAndFeel; the file comment says why appearance and behaviour are kept apart.
Restyle a plugin by subclassing this (or one of the LookAndFeel_V1 to V4 versions) and overriding the palette first, then any draw call, and hand it to a widget with setLookAndFeel -- everything inside that widget inherits it. Widgets keep a raw pointer and do not own it, so it must outlive every widget it was given to (a member of the editor, declared before its widgets, is the usual place). The draw calls run during paint, on the message thread. Without one, a widget uses defaultLookAndFeel().