# Programmatically building a UI for any object **URL:** \ **Category:** General JUCE discussion\ **Created:** [March 8, 2019, 9:51am UTC](https://forum.juce.com/t/programmatically-building-a-ui-for-any-object/32165 "2019-03-08T09:51:43Z")\ **Posts on this page:** 12\ **Page:** 1
**Author:** ![ans](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/ans/32/617_2.png) [@ans](https://forum.juce.com/u/ans)\ **Post date:** [March 8, 2019, 9:51am UTC](https://forum.juce.com/t/programmatically-building-a-ui-for-any-object/32165/1 "2019-03-08T09:51:43Z")
Please bear with me if this is a stupid question, but I’m looking for a way to dynamically build editors (components & widgets) based on data at runtime. Let’s say I have 200 subclasses of some “Generator” base class, each of which needs an editor to configure instances. Obviously, instead of manually coding and hard-wiring 200 custom components, I want to supply each class with a method that declares the widgets and bindings to member functions as some literal data. Pondering this, a few questions arise: What’s the best way to keep generic components? Would a HashMap or other owning container do? How to distinguish between component types (templates vs. dynamic cast)? How to dispatch change notification messages to member methods symbolically (i.e. by name)? Has anyone already done this? A few hints as to which direction to take would be very helpful. TIA ---
**Author:** ![matkatmusic](https://avatars.discourse-cdn.com/v4/letter/m/dfb087/32.png) [@matkatmusic](https://forum.juce.com/u/matkatmusic)\ **Post date:** [March 8, 2019, 10:01am UTC](https://forum.juce.com/t/programmatically-building-a-ui-for-any-object/32165/2 "2019-03-08T10:01:56Z")
> [@ans](#): > > What’s the best way to keep generic components? `OwnedArray components;` > [@ans](#): > > How to distinguish between component types (templates vs. dynamic cast)? probably ```auto if( auto* p = dynamic_cast( components[i] ) ) { } else if( auto* t = dynamic_cast( component[i] ) ) { } //etc ``` > [@ans](#): > > How to dispatch change notification messages to member methods symbolically (i.e. by name)? have a look at this talk: [![](https://us1.discourse-cdn.com/flex026/uploads/juce/original/2X/c/c5649877bbf425b76c2a5351b8be6a6c30fb7fa8.jpeg "David Rowland - Using JUCE value trees and modern C++ to build large scale applications (ADC'17)") ](https://www.youtube.com/watch?v=3IaMjH5lBEY) the part about ValueTreeObject is what you’ll be interested in. It sounds like you’re trying to write something like Reaktor. ---
**Author:** ![ans](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/ans/32/617_2.png) [@ans](https://forum.juce.com/u/ans)\ **Post date:** [March 8, 2019, 11:16am UTC](https://forum.juce.com/t/programmatically-building-a-ui-for-any-object/32165/3 "2019-03-08T11:16:46Z")
> [@matkatmusic](#): > > It sounds like you’re trying to write something like Reaktor. Yes, that sort of application. Thanks for your input. I would like to build the entire application’s UI on a declarative approach that does away with member variables for individual components. Also the various \*::Listener protocols seem overly static. I would much prefer attaching a method to every component individually, so these can be inherited, overridden and maintained on a per-widget basis. The question is just how to establish that link at runtime. ---
**Author:** ![daniel](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/daniel/32/790_2.png) [@daniel](https://forum.juce.com/u/daniel)\ **Post date:** [March 8, 2019, 11:27am UTC](https://forum.juce.com/t/programmatically-building-a-ui-for-any-object/32165/4 "2019-03-08T11:27:31Z")
> [@ans](#): > > Also the various \*::Listener protocols seem overly static. I would much prefer attaching a method to every component individually, so these can be inherited, overridden and maintained on a per-widget basis. The question is just how to establish that link at runtime. This is very handy during prototyping. Some Components like Button provides std::functions you can populate at runtime, like [`std::function Button::onClick`](https://docs.juce.com/develop/classButton.html#a30b76ab312dc7f66e67596ae20540ec2). But the Listeners have also advantages, like once an interface is established, and the listening component wants to react to 5 different signals, a single `foo.addListener (bar)` does it all… Also with the lambda approach, it is way too easy to violate the DRY principle. ---
**Author:** ![ans](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/ans/32/617_2.png) [@ans](https://forum.juce.com/u/ans)\ **Post date:** [March 8, 2019, 12:31pm UTC](https://forum.juce.com/t/programmatically-building-a-ui-for-any-object/32165/5 "2019-03-08T12:31:00Z")
Just watched the ADC’17 ValueTree talk and must say I’m impressed by that work. ROLI rocks! I think ValueTree could be viable for those generator UIs, as the scope of value types is limited and well defined. I now wonder if it makes sense to turn an entire app’s data model (e.g. the “song”) into a ValueTree. I got 50 or so comparatively complex data classes and megabytes worth of data (not audio). My current approach is to have data know nothing about it being edited (no listeners attached to data). It’s just the leanest possible data laying bare. Then there are tools that navigate and edit the data, taking responsibility for broadcasting change notifications globally. Views and other tools can subscribe to these notifications. Tools know about semantics and higher-level dependencies, so they can condense notifications to a minimum, e.g. collapse multiple changes into one. But this is a different, more general topic, of course. (Ha! If this was an easy task, it wouldn’t take so many people to chew on it for decades and bring up so many different solutions and approaches) ---
**Author:** ![daniel](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/daniel/32/790_2.png) [@daniel](https://forum.juce.com/u/daniel)\ **Post date:** [March 8, 2019, 12:38pm UTC](https://forum.juce.com/t/programmatically-building-a-ui-for-any-object/32165/6 "2019-03-08T12:38:38Z")
Agreed, in fact I also started to work on that a few years ago, to create the whole GUI and it’s Layout from ValueTrees. The Layout part exists and works: [github.com/ffAudio/ffLayouts](https://github.com/ffAudio/ffLayouts) My plan was to do the Components as well via [ComponentBuilder](https://docs.juce.com/develop/classComponentBuilder.html), but I found the serialisation and deserialisation not very well documented, and the communications on the forum gave a strong hint, that there won’t be future development on ComponentBuilder (it’s fate is tied to Projucer’s GUI-Editor). The other reason against this approach is, it is so convenient to have the actual types of components while writing the business code behind the GUI. But a fresh take on creating GUI from declarations like XML/CSS or declarative or other options are worthwhile to explore. You will find several threads in the last half year here on the forum. ---
**Author:** ![ans](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/ans/32/617_2.png) [@ans](https://forum.juce.com/u/ans)\ **Post date:** [March 12, 2019, 11:02am UTC](https://forum.juce.com/t/programmatically-building-a-ui-for-any-object/32165/7 "2019-03-12T11:02:36Z")
Thanks for the heads up re ComponentBuilder. Maybe Projucer’s GUI-Editor will have a second life after a GUI framework emerges, whose editor could re-use much of its code. It may benefit from what ComponentBuilder already does. I think ValueTree XML looks like a good file format to use. ---
**Author:** ![jules](https://avatars.discourse-cdn.com/v4/letter/j/41988e/32.png) [@jules](https://forum.juce.com/u/jules)\ **Post date:** [March 12, 2019, 11:11am UTC](https://forum.juce.com/t/programmatically-building-a-ui-for-any-object/32165/8 "2019-03-12T11:11:02Z")
Please don’t use ComponentBuilder! It was a failed experiment and will be removed at some point… it’s just left there for backwards-compatibility for the moment. (…and it could certainly use some comments to explain this too!) ---
**Author:** ![anon48770766](https://avatars.discourse-cdn.com/v4/letter/a/439d5e/32.png) [@anon48770766](https://forum.juce.com/u/anon48770766)\ **Post date:** [March 23, 2023, 1:55pm UTC](https://forum.juce.com/t/programmatically-building-a-ui-for-any-object/32165/9 "2023-03-23T13:55:55Z")
@jules, sorry to revive a dead thread, but is there any thoughts on an alternative to ComponentBuilder in JUCE’s future? It seems useful at first glance, but taking your advice at heart it appears unwise to dig further … so is there some alternative to ComponentBuilder planned/already implemented (that I’ve obviously missed so far…) ---
**Author:** ![daniel](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/daniel/32/790_2.png) [@daniel](https://forum.juce.com/u/daniel)\ **Post date:** [March 23, 2023, 2:06pm UTC](https://forum.juce.com/t/programmatically-building-a-ui-for-any-object/32165/10 "2023-03-23T14:06:57Z")
Soon after this thread I started writing PluginGuiMagic, which picks up on the idea creating a GUI from a ValueTree. It is not from the juce team though, but maybe it works for you. > **[GitHub - ffAudio/foleys\_gui\_magic: A GUI builder module for JUCE](https://github.com/ffAudio/foleys_gui_magic)** > > A GUI builder module for JUCE. Contribute to ffAudio/foleys\_gui\_magic development by creating an account on GitHub. PGM features runtime editing, flexbox and proportional layout and allows to wrap arbitrary Components in addition to many existing juce components and signal visualisers to be managed. ---
**Author:** ![JeffMcClintock](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/jeffmcclintock/32/21430_2.png) [@JeffMcClintock](https://forum.juce.com/u/JeffMcClintock)\ **Post date:** [March 23, 2023, 10:54pm UTC](https://forum.juce.com/t/programmatically-building-a-ui-for-any-object/32165/11 "2023-03-23T22:54:57Z")
> [@anon48770766](#): > > but is there any thoughts on an alternative to ComponentBuilder in JUCE’s future? FYI. I am working on integrating my drag-and-drop GUI designer into JUCE. However, it does have the tradeoff that it uses a completely different Graphics framework. And also that it is a work in progress. So probably not ready for prime time yet. ![](https://us1.discourse-cdn.com/flex026/uploads/juce/original/2X/2/2fef667388da1e866efaeaa746780de853bdd88f.gif) ---
**Author:** ![anon48770766](https://avatars.discourse-cdn.com/v4/letter/a/439d5e/32.png) [@anon48770766](https://forum.juce.com/u/anon48770766)\ **Post date:** [March 24, 2023, 8:22am UTC](https://forum.juce.com/t/programmatically-building-a-ui-for-any-object/32165/12 "2023-03-24T08:22:34Z")
These are both very nice tools to investigate - thanks guys! PGM looks pretty feature-rich …