Isn't it a bad practice to call setDefaultLookAndFeel()?

Hi folks,
isn’t it actually a bad practice to call

setDefaultLookAndFeel() 

which is calling

    Desktop::getInstance().setDefaultLookAndFeel (newDefaultLookAndFeel);

itself?
There is one defaultLookAndFeel per process, but this would mean this method could even change the lookAndFeels between different vendors?

Or do I missunderstand something here?

Great question!

See here for some related discussion. My take is: if you are developing plugins then avoid using setDefaultLookAndFeel()

Using any sort of singleton in a plugin is likely going to lead to issues - unless you’re only using it read-only.

That being said, assuming all instances of your plugin use the same LaF, there’d be no harm in calling setDefaultLookAndFeel() - afterall it’s only a default, you can always explicitly specify a different one for specific instances.

In general though, the more explicit approach of setting a look-and-feel on the top-level component is usually the way to go.

no! It will not be shared above dll/plugin boundaries.
But multiple instances of the plugin (if the host uses mutiple instances in one process) will use the same look and feel.

Imho its best practice to use a SharedResourcePointer, which guarantees that you only once initialise the LookAndFeel for multiple instances.

(As long you don’t want to use different LookAndFeels for the different plugin instances of the same plugin, which is rather unusual, than better apply the look-and-feel on each top-level-component)

Whether you call it or not, there is a specified defaultLookAndFeel which is LookAndFeel_V4. So anything that relies on the defaultLookAndFeel lookup will use that. So whether you call it with something other lookAndFeel or not (in your plugin), your plugins will all share the one you specified, or juce::LookAndFeel_V4, so I’m not sure what the difference is?

Ok thanks people for the answers.
I made it now with setDefaultLookAndFeel in Standalone and the other way around in the plugin.