Thanks! Just merged it. I added nightly CI runs. I also added you as a collaborator, to ease any future contribution. There’s a rule that CI has to pass and one other person has to review and merge. There’s a few of us (me, baconpaul, figbug) able to do that.
Locally, this is a known bad interaction with Ninja and root-level JUCE modules building in-source. Still determined to fix vs. have to restructure the project / tell everyone to build out of source. I’ll add some notes to the docs for now to instruct to avoid Ninja or build out of source (only applies when running top level).
I like how the inspector lets you move components around and change properties such as visibility.
I wonder: would it be possible to add designing/drawing? Like, how Figma let’s you do it.
I don’t think you can override paint calls from the “outside”, though? So you would probably need new component classes to derive from? Hmmm…
I saw you mentioned Foleys gui magic.
Ideally I would like to send a plug-in to a designer and he could design it directly inside of the live plug-in. Like, instead of him designing it in Figma first, he could design it directly in some kind of “juce editor” which has similar capabilities as Figma. Eliminating the stage where I have to take the Figma design and copy it into code.
Just daydreaming a bit here. But would be nice to have!
@sudara Yes, custom components are supported. I’ll work on a demo of how to read/write a custom class.
The component tree is created from xml using a function like this. (Good enough for a demo; packaging could be improved.)
We use create new components from a template list. The component template list and the component tree are built with the project as juce binary resources; we also search on the desktop for files named ComponentTemplates.xml and MainComponent.xml, which if present override the base resources. this allows for iterative UI dev without recompilation.
Oh this is cool! How does this impact FlexBox editing, out of curiosity? (FlexBox are one of my pet peeves at the moment, too many recent tweak/compile/test cycles and resulting brain-fry…)
Would be great to see these enhancements get merged into the main (sudara’s) repo as quickly as feasible .. I have a few projects where I use melatonin-inspector, but can’t easily change the config for a different repo source .. but I’d be definitely a happy customer of new melatonin-inspector features..
