LookAndFeel_V2::getTextButtonFont


#1

Before we could return the actual font of the TextButton but now it returns a new (default) Font set to the correct size… what happens if the font was not the default? (Since TextButton::getFont() is now private).

Rail


#2

Sorry, I don't understand the question..? Surely you can override the L+F method to return any font or size you like?


#3

Well my L&F used to have:

Font CToggleButtonLookAndFeel::getTextButtonFont (TextButton& button)
{
    Font f;

    f = button.getFont();

    f.setHeight (11.0f);

    return f;
}

but in the new tip TextButton::getFont() is private and you have replaced it with

Font LookAndFeel_V2::getTextButtonFont (TextButton&, int buttonHeight)
{
    return Font (jmin (15.0f, buttonHeight * 0.6f));
}

I would have thought it should be:

Font LookAndFeel_V2::getTextButtonFont (TextButton& button, int buttonHeight)
{
    Font f;

    f = button.getFont();

    f.setHeight (jmin (15.0f, buttonHeight * 0.6f));

    return f;
}

It just seems that getTextButtonFont() isn’t really returning the true TextButton font… say the TextButton font was changed to a different typeface before calling getTextButtonFont() it’ll return the wrong font.

This doesn’t affect my code, but it just struck me as “not right”…

Best,

Rail


#4

Huh? Sorry, I don't understand..

I removed the TextButton::getFont() method. It no longer exists. That L+F method is now the only place where the font is defined, so it has complete control over the one that will be used.


#5

Okay, I see what you’ve done… I was thinking the font was still a member of TextButton.

Cheers,

Rail


#6

While I can understand the logic, it's sometimes interresting to overide per instance some values.

Font is something that you may want to change on per Button basis and you don't want to have a custom LnF just for this as this is quite painful especially as the LnF is not referenced counted so you need to handle its lifetime.

I would'nt mind if you could reverse this.

LnF is great, but for the same reason that you allow colours to be defined on the component itself, I find that forcing some minor customization to be only possible in the L&F to be counter productive

 

Thanks !

 


#7

What you're asking for would be a similar system to the way colours are handled, which works fine but would be a bit tricky to extend to fonts. If I was to add this, I certainly wouldn't just add it for this particular class, it'd need to be something that was more generally used, like the colour IDs are - but it'd take a lot of thinking about to implement it correctly, and wouldn't be a priority for me at the moment.


#8

Yep a bit indeed. I'll go the hard way in the meantime.

 

Thanks !