Subject: Enhancements for Beginner-Friendly GUI Development in Projucer

The Projucer
1

Dear JUCE Community,

I’d like to start by expressing my appreciation for the outstanding tools you’ve developed. The GUI editor in Projucer, in particular, is an invaluable tool, especially for those like me who are new to JUCE and C++.

However, as a novice developer, I’ve found that the process of setting up and connecting a GUI using Projucer could be more beginner friendly. After designing a GUI in the editor, I found myself having to manually delve into the generated C++ files, which can be daunting for someone new to the language.

While I understand that automating these kinds of processes might limit the flexibility that seasoned developers value, I believe there could be a balance that caters to both ends of the spectrum. It would be incredible to have a “plug-and-play” experience with the GUI editor where, after designing a GUI, we could build and run a basic application or plugin right out of the box, even if the knobs and sliders don’t yet control anything.

Such an approach would allow beginners to focus on higher-level concepts and more creative aspects of development initially. Then, as they become more comfortable, they could delve into the lower-level code that provides more control and flexibility. This incremental learning path could be less overwhelming and more encouraging for those new to JUCE and C++.

I’m eager to hear the thoughts of other community members on this matter. My hope is that this discussion can foster ideas that make the learning journey smoother for beginners, while retaining the flexibility and control that makes JUCE such a powerful tool for more experienced developers.

Thank you for considering my feedback.

Best,
Marquavious Jaxon

2

Correct me if I’m wrong, but as far as I know, the GUI Editor in Projucer is considered “deprecated”. Maybe it still works, but it’s going to generate all sorts of confusing stuff that would not normally be there in a “real” JUCE project. You are far better off going through the tutorials one by one and learning the correct way to create a GUI by having knowledge of the underlying framework.

3 Likes
3

Personally, I think creating beginner-friendly high level UI tools isn’t the role of the JUCE team, and I would not like they spend any time/resources on it.

Instead, I’d suggest you look into community-made high level GUI editing tools for JUCE such as PluginGuiMagic and JIVE that are made for a similar purpose.

5 Likes
4

I wouldn’t suggest anyone spend their time on something that isn’t worthwhile to them - The JUCE team have always chosen their battles wisely, there is little evidence of their being distracted by blue sky ideas, much - so I don’t think this thread is necessarily about who does what with the framework, but rather where does the framework go next … and we don’t need to go far, to get some interesting results.

For example the .jucer file format is ripe for adding new GUI nodes. It could all be stuffed in there. Standardized SVG nodes could be glommed, where the JUCE GUI parameter conventions are mapped to SVG attributes, fairly easily. We just need to decide how much to stuff into our custom Jucer node, and whether its juce(svg) or svg(juce), in terms of encapsulation.

Projucer could have its own uroboros-like GUI playground. I believe it was deprecated because the interest wasn’t there, and it was a big thing to maintain at the time - perhaps less so now, however.

All we really need to do is build a decent XML Editor Component, bind it to some runtime instantiation of any Node(SVG/otherwise) pointing to a JUCE Class it understands, and we’ll be as close to a WYSIWYSG editor as ever.

On the other hand there are plenty of other cute hacks that could be done. The pipe going: SVG → C++ Object → SVG is a cute low-hanging fruit, for anyone really - not just the JUCE team. I’ve seen game dudes stuffing everything into .svg and editing in Inkscape, level-design and all, and using the onboard XML Editor to tweak settings effectively during game design … that could happen in JUCE-land too. The key thing is to establish a convenient ontology between SVG and JUCE GUI Component classes, derive some conventions, and work out the places to touch as little code as possible.

2 Likes
5

Thanks @eyalamir for the shout out.

The Projucer relies on the ComponentBuilder, which is not extendable. Also the format of the XML/ValueTrees to serialise the Components is not documented, because it was not intended as public interface.

There are so many different ways to create GUIs, so a one fits all approach is virtually impossible.
That’s why different GUI engines make sense. They differ in requirements/what they solve and in terms of what language/data model to use.

There are GUIs that always present one view of knobs and visualisers. They are pretty static (sometimes resizable) and coming up with a GUI layer is pretty straight forward.

That is what my PluginGuiMagic aims for. Adding decorators for round shapes, gradients and other effects is the main goal. A cascading logic to define properties a’la CSS makes declaring a logical UI possible with little copy paste.
It also features rules for responsive layouts, so it adapts the format and size of the GUI.
It is already possible to create Tabbed views and it is planned to also allow flows like a wizzard UI with multiple pages.

What it does not, is adding scripting. That was first intentionally, because the audience was designers to provide the UI for others who did the DSP side of things. But I understand it would be nice to allow it for those who are able to do it.

I think the project from @ImJimmi follows pretty much my approach, but I only skimmed over it briefly.

What also makes it hard for Projucer is, that many Components need to be separated into a persistent state that lives in the AudioProcessor, e.g. because it processes audio for say a meter or a MidiKeyboardComponent, and the view, that can be created and destroyed at any time the host sees fit.

A different approach is to use e.g. react like @ncthom react jcue, but I think it changed the maintainer and I am not sure of the current state.

And in the same direction I saw attempts to use webviews in plugins. It was said to be resource hungry, but once that becomes workable, it might open up a lot of options.

2 Likes
6

There is this that’s recently been released : GitHub - maxgraf96/ultralight-juce: Integrating the Ultralight C++/HTML renderer with JUCE for prettier UIs.

It looks interesting, but unfortunately useless to me due to the (kind of mental imo) $2k/app/year license for UltraLight once gross income for a company hits $100k. Even the inability to statically link UltraLight for FOSS projects makes it a little troublesome, since most posts I’ve seen on here regards using 3rd party libraries suggest that statically linking is the way to go for audio plugins, unless you want a heap of potential problems.

1 Like
7

IMHO, the web is one of the worst-designed UI models in existence, the product of a physics nerds’ feverish dream, whose crazy fluke of a project gained insanity of mass adoption merely by stint of being the first (and among the worst) of the apps to truly use TCP/IP, while proper software engineering practices were thrown out of the ether…

Please for the love of god, embrace SVG and generalize your events as close as possible to the conventions of your primitive library.

Throwing a webview at it, kills the plugin.

(Disclaimer: good to have it as a tab for documentation, though…)

/ducks

2 Likes