LnF stub/fowarder

Would be great to add by default a LookAndFeelForwarder which forward all functions to an instance given in the ctor but still allowing to override couple of functions by deriving from it.

It allows to only override the current LnF for couples of functions without knowing what is the current class used.

Hope you see what I mean.
The tricky part is that it should be maintained with the trunk as it should forward all the LookAndFeel interface functions.

Thanks !

1 Like

Can you show an example snippet of what you mean? Maybe I read that too fast, but that was really confusing to me lol

Something along

class LookAndFeelForwarder : public LookAndFeel
LookAndFeelForwarder(LookAndFeel *pLnf) : mpLnf(pLnf)

 virtual void drawPropertyPanelSectionHeader (juce::Graphics& g, const juce::String& name,
                                                 bool isOpen, int width, int height) override
return mpLnf->drawPropertyPanelSectionHeader(g, name, isOpen, width; height);

virtual void drawPropertyComponentBackground (juce::Graphics& g, int width, int height,
                                                  juce::PropertyComponent& component) override
return mpLnf->drawPropertyComponentBackground (g, width, height, component);
LookAndFeel *mpLnf;

but for all functions

How is that different from just subclassing LookAndFeel and calling LookAndFeel::paintButton in your overridden paintButton call? what am I not getting?

struct MyLookAndFeel : public LookAndFeel
   void paintButton(Graphics& g, bool a, bool b) override { LookAndFeel::paintButton(g, a, b); } 

In case you want to customize the LnF of a widget in a hierarchy where you don’t know what the current LnF is and can only get its pointer by asking the parent widget.
If you do custom widget, they can be used in different context hence different base LnF

can’t you just make your widget that you want customized (differently from your existing LnF) just override the paintButton or paintWhatever directly?

struct MyButton : public Button
    MyButton() { setLookAndFeel( myLookAndFeel ); }
    void paintButton(Graphics& g, bool, bool ) override { /* customize however */ }

is that not something we are allowed to do if we use LookAndFeel?

@jules thought ?

Yeah, no objections to the idea!

Can you help me understand why my offered solution doesn’t solve the problem?

Because your solution only works for stuff where the LnF is called by a virtual function that you can inherit and force to do the whole impl of the paintButton instead of just a color settings or something like that.

so, this is bad

void paintButton(Graphics& g, bool, bool ) override 
    setColour( /* customize your LnF colors and stuff you want the base class to use */ );
    Button::paintButton(g, bool, bool );

Or not even possible? I haven’t spent much time with LnF, so I’m genuinely curious about how you ended up needing to have this as a solution for a problem I haven’t had the pleasure to try to solve myself.

Probably because you don’t have a complex apps with a framework with already made widgets.

Your solution works for setColour but not for other stuff like getTickShape or equivalent.

Don’t you have to implement getTickShape entirely if you want/need to customize it? How does your LnF forwarder get around that? I must be missing something about this…

The issue is not about implementing getTickShape entirely, the issue is that unless you know which LnF is currently used you cannot forward to the current one for the other function related to this widgets or the hierarchy below if your widget is a container.