Of course this would require adding setMetric, findMetric, metricChanged methods analogous to those for colors. But it seems logical. And would improve robustness for maintaining styling consistency across an app.
matkat - are you linking to the component properties? If so, that’s not analogous to the set/find color system because there are no associated events, and props can’t defer to look and feel.
Currently I have methods for getting style data (other than colors) in a derived LookAndFeel class, and I dynamic_cast the component’s LAF to get them. But this makes my components dependent on a particular LAF class.
It still seems logical to me that the system for getting colors should extend to other types of lightweight styling data.
Well – then all my components need to have a style value tree? I think that’s more clumsy than my current solution!
I’m just being picky about logical consistency here. Why are colors given higher status than other types of lightweight style data? I suppose it’s more of a philosophical matter as Jules is not keen on adding Component methods.
TBH it’s mainly just historical - a lot of the UI classes are extremely old, and the colour stuff pre-dates the LookAndFeel classes (which themselves are pretty old and could use a lot of modernising)