Is anyone using the ComponentBuilder class?

1

I’d really like to deprecate it, but just wanted to check first, in case this would be a terribly unpopular move…

2

I’m pretty sure all our synth UIs are built with this…

3

How can you be just “pretty sure”?

4

Because another developer in in charge of those projects and I haven’t opened them up to take a look yet. So I’m “pretty sure” but not “certain”.
I will of course check when I get a moment but I just wanted to voice this quickly first.

I was also about to extend this by saying that I wouldn’t mind it being removed from the library, I think we can just take a local copy of it and use that but again, I’m not massively familiar with it and haven’t thought through all the possible ramifications etc. yet and if there’s something in JUCE itself that we depend on it being there for.

5

@Rail_Jon_Rogut Wasn’t there a project you were working on that was using this?

6

Hi Joël,

Yes there was… and I was just catching up on busy work before I could respond :slight_smile:

I used this class extensively in a proof of concept project where the project had an interactive GUI builder… It’s something I still have, but not actively being developed at the moment… but the class made sense and worked well for the project at the time and allowed for a fairly rapid development of the feature. Having it deprecated seems like it would be a loss IMO…

Thanks!

Rail

7

OK, thanks for the feedback. My motivation in looking at this is really to try to clear the ground for a different-but-better approach to dynamic GUIs. I won’t scrap it just yet, will have a think, but might add a comment suggesting people avoid it in new code.

8

I was digging into it a year ago, because I wanted to merge the projucer gui designer (it uses ComponentBuilder, IIRC) with my QT-style layout engine, but that never happened…
So I am curious, what the replacement will be. Looking forward!

9

Late post, but full on topic: I did not yet use it, but am pondering over a similar thing in an attempt at a “different-but-better approach to dynamic GUIs”.

IMO it would be of great value, if all Components were able to save their configuration (colors, labels, layout, etc) to ValueTree and vice versa (like many other objects do with XML). With this uniform protocol for serialization and (re)building in place, coming up with a more sophisticated UI framework should be a lot easier. Even different frameworks could peacefully coexist.

So before eventually deprecating ComponentBuilder, moving its ValueTree support to individual Components would make for a great foundation to build on.

1 Like