Well what I’m saying is that we didn’t use to have several LAFs that drew everything, then I had to add support for multiple, user defined colour schemes, then half the drawing looked terrible and the only sensible way to fix it was to create multiple LAF instances. For example, we have at least a dark and light LAF and also a “simple” LAF for low-cpu usage (although these days I’ve simplified that by having a “low-detail” member in the LAF that is checked in all of the drawing methods to avoid overly complicated shapes and shadows etc.).
I guess it comes down to personal preference but in general I’ve simply found it much easier to reason about our drawing since moving towards everything having LAF methods rather than being hidden in Component subclasses.
I think maybe we’re talking at slightly cross purposes as for button there is generally less difference. For sliders though, we have multiple styles that can absolutely change dynamically depending on if they have active modifications (like LFOs etc.) or are currently being assigned to from MIDI etc. When you have components that change the way they look on a very dynamic basis like this, I’ve found it easier to use dynamic variables like properties to determine this behaviour. For static components, maybe a button subclass is more explicit.
In all honesty we have a mixture of both of these methods depending on the purpose. We do have a “StandardButton” class that draws most of our buttons but I’ve never particularly liked that. We also have several different button subclasses that have special behaviour but again, these are probably there because they predate
std::function and the much more customisable way of using buttons these days.
I guess the overriding thing for me is that in my
Component building I think of “this is a button, users will click on it to trigger some event”, in my
lookAndFeelChanged method I think “some UI related property has changed, update the button properties to reflect this”, then in the LAF methods I think “this is how I draw a button with these properties”.
Again, maybe not necessary for small apps but I’ve found this scales much better for our use cases.