findMetric like findColour?


#1

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.


#2

see
https://docs.juce.com/master/classComponent.html#a23985453622396b6037eb5ec38dbd398

and also the LookAndFeel system


#3

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.


#4

maybe you could use a ValueTree with no nested children?

https://docs.juce.com/master/classValueTree.html#adc7c731c09608f59e9372b9221e35a17


#5

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.


#6

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)