findMetric like findColour?


Jules - I really like the setColour / getColour component methods.

Question: why are these methods only written for color properties? Why not have analogs for other styling properties like font sizes?

void MyComponent::paint (Graphics& g)
    g.setColour (findColour (ColourIds::myFontColour));
    g.setFont (Font().withHeight (findMetric (MetricIds::myFontHeight)));
    g.drawText (...);

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.



and also the LookAndFeel system


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.


maybe you could use a ValueTree with no nested children?


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)