can the Gui Component be fixed so it can work with ValueTree?
since i cannot remove the auto generated
gainSl1 = nullptr;
in Gui.cpp
and i cant place
ScopedPointer<Slider> gainSl1;
above
ScopedPointer<SliderAttachment> attachSliders;
in Gui.h
i get an access violation when running the build.
As far as I’ve understood, the GUI designer in the Projucer is no longer really meant to be used.
so is it an abandoned tool and no longer developed / updated?
It would appear so but it would be good if there was some kind of an official statement about that because people new to Juce regularly do attempt to use it and then discover the limitations and other issues.
yes, that would be great, i am one of those people.
We’re not going to actively work on the GUI builder - people might want to use it to get started, but that kind of static GUI tool is always going to be limited, so when you hit something it can’t do, you probably need to move on and start hand-coding your classes.
The GUI tool is very useful for early ui / functionality prototyping but usually you’ll move forward as the UI/UX designer comes in and the product gets more mature.
Those days if it’s pure dsp you’re focused, you might be better off with GenericAudioProcessorEditor instead of wasting time on the editor at early prototyping.
something on-topic:
you could delete the sliderAttachment in the [Destructor_pre]
attachSliders = nullptr;
@chkn right! and this solves every thing! thanks! 
also this access violation happens when i build on visual studio.
someone tried on xcode and said it works and exits fine.
@jules oh its really a pity to hear that. WYSIWYG is a nice thing to have for GUIs
i hope it doesnt get removed or stops working in later JUCE builds. hope at least it gets passively worked on
Well, it seems like a nice idea, but in practice I’ve found that almost no real-world GUIs are simple enough to be designed in this kind of tool. Sure, occasionally there’ll be a dialog box or something trivial, but even those are better laid-out with flexbox nowadays.
Maybe one day it will be replaced by a Flexbox-WYSWYG editor?
If one searches the forum for “layout”, there are several projects (including one of myself, but mine is not flexbox but XML)…
For me, it’s fine if it’s not actively developed, but I’d be sad if the designer were pulled out of the Projucer – I keep a separate scratchpad project just to drop components into because it’s easier do things like spec colors there than to look up the ID values, etc. The real work for anything more complex than a prefs dialog still gets handcoded, even if it’s using that generated test code as a reference.
Yeah, we’ve no plans to remove it.
One of the good things about it is that if you don’t know anything about JUCE and/or C++, it’s handy to demonstrate what the code looks like to do simple GUI operations.
The annoying thing about it is that it could use a good clean-up - it was written before ValueTrees, and could be much, much simpler if it was rewritten to use them, but there’s a ton of code in there and it’d be a big job! It’d also be nice to update it to use lambdas instead of listener callbacks.
@daniel i seached for layout and found many interesting posts. thanks
i will definitely try your Layout class for GUI prototyping
and New layout system for JUCE from @lostmarble1
@jules yes, i see you mention Gui editor is legacy in other posts, sorry for that.
so anyway, maybe the GUI editor is a nice place for people that want to try their flexbox, xml, lambda or whatever implementations and we could someday be lucky and get a community update
The big exception is Apple’s interface builder - plenty of extremely complex/pro apps (particularly 99% of Apple’s first/second party apps) are set up via Storyboards/NIBs since it massively speeds up the workflow for both designers and engineers.
If Projucer’s GUI editor could somehow support custom Component classes, lambda based callbacks settable in the editor (like IBActions) and a FlexBox based constraint system… it would probably be pretty dang powerful. Obviously that would be a colossal undertaking that could probably be better spent elsewhere…
