Hi Jules,
Is there a reason, for us users, to be forced to delete our own default LookAndFeel which is set using the LookAndFeel::setDefaultLookAndFeel(…) ?
If we don’t provide any L&F, Juce creates a default one, called “LookAndFeel” and this is autodeleted with the help of a ScopedPointer.
Granted that it’s easy to use a ScopedPointer in the App class, but I’m having difficulties seeing how to do this in a plug-in, if you understand what I mean.
Grateful for your insight.
There’s no reason to use a ScopedPointer, I just generally embed the lookandfeel object in the app class - have a look at how the introjucer does it. Clean, simple, no deletions or pointers required.
Yes, very clean.
But…
How would one use a defalt LnF in a plug-in, having no such thing as an App class.
You can’t place it in the AudioProcessor class.
Put it in the editor class?
No!! Because if you instantiate 2 plug-ins from the same binary and open their 2 editors, “1” and “2” you will first refer to the LnF of instance 1, then 2. Then if you close editor 2, editor 1 will go nuts!
Yeah, obviously if you set it as the global l+f it won’t work, but if you just make it the lookandfeel for that editor component, it’ll be fine.
If you really need to share a l+f (or any kind of data) between instances, then you’d want to have a shared, reference-counted class to hold it.
Perhaps you thought I meant that you put one LookAndFeel to the editor window itself, not as a system default. I believe all children would inherit this? In that case you’d be safe, but there are other things that may pop up that are outside the control of the editor, such as AlertWindows.
Granted that a plug-in should never ever do anything modal, but could it not happen?
I wrote my post after you posted yours. Doh…
Which brings me back to the original question. The juce class LookAndFeel is managed through a ScopedPointer.
I wish I wish I could squeeze my own LnF in there. No?
If it deleted the object you give it, then it’d be impossible to use non-heap-based objects (like in the introjucer).
Of course, but in many places you use the term “Owned” and “NonOwned” such as in ViewPorts etc…
Currently, I do have a reference counted mechanism that takes care of everything. I don’t like it though; I rather put the LnF directly on the editor class because that makes the most sense. I’ll look into all the places I use AlertWindows. The ones I have are only for critical error messages, and will probably not be in there in the end user version.
