Is there anyone out there prototyping, or using other frameworks other than Juce for their UI design? As a producer (non developer), I’m finding the GUI portion to take the most time when developing apps. There are tools like PaintCode, JavaScript Canvas, and tools like QT have very feature rich and flexible GUI programming tools.
More specifically and to be blunt, I want the graphics guys to handle the GUI side with minimal code and drag and drop-able abilities, while I let the devs handle the programming side. We all know you devs hate GUI stuff
Anyone using other frameworks for the GUI, while using the Juce classes.
In my current app I use a sort of custom-rigged setup with sketch.
The UI guys make a sketch file, then I export the coordinates for the various UI elements as JSON. I can then load that layout into the app.
My app consists of a set of various views that mostly have standardized components, so we are able to generate the entirety of the UI dynamically through JSON that creates and positions components as necessary. It works very well, but it took a bit of time to set up. I hope JUCE at some point supports XML or JSON UI layouts.
Previously I was using React Native. I loved it and will surely use it again — it was very simple to even use custom JUCE components within Javascript & React Native, plus it is familiar to anyone who does web UIs.
I only stopped using react native because I switched companies, lol.
I will definitely use it again - my current project is a traditional JUCE GUI just for prototyping - we didn’t want to add extra dependencies or extra work for something that is just transitionary anyway. We are switching to Unity soon (with JUCE & our code as a dll) because we have some heavy 3D graphics and a game engine seems like the best choice for that.
My custom sketch routines are pretty tightly coupled with our specific project, but I’ve been wanting to make a JUCE sketch plugin for a while… may actually start it now.
100% agree on having a sketch plugin that at least generates scalable components based on the Sketch elements. One thing that does need fixing for this to work is JUCE’s svg parsing by adding support for basic shadow types that designers use all the time in Sketch.
no, not from what I can see. You could render out the shadows as a png and overlay the svg by hand, but that breaks the exporting of a single svg element in Sketch and I’d imagine would cause push back from design. Also pngs for shadows mean that they start to look weird when you scale the interface, especially if overlaid and thus contrasted with the sharp svg scaled elements.
So time constraints led me to drop learning Sketch plugin syntax, but I found an already existing plugin to export QML from sketch.
I feel like a better solution would be to make a simple tool to just convert QML to JUCE components — could have useful applications outside Sketch. Will be investigating this over the next month…
Very interesting idea with using Unity as GUI layer! If you have already gone this direction, did you encounter any issue while using your juce .dll in Unity, since its written in C++?
Also, why not Unreal Engine since it would keep language consistency?
I didn’t have any issues with this — however, JUCE has since added Unity Plugin as an export target — this makes it very easy to do the JUCE <=> Unity stuff instead of rolling your own like I did.
Unreal Engine sounds great too! The company I worked for was stuck with Unity though.
Awesome thanks a lot!
Did you encounter any performance issues, having the GUI in C# ?
After I read your post I just had to find out more about the integration with Unity, since I literally had no clue this was possible, and oh my god sweet moses I found this blog post from JUCE from literally today, where this is announced
I didn’t have any performance issues — I created the whole app as if it were just a Unity app, and it wasn’t too intense of an app anyway. Unity is definitely performant if you use it right!
All the synths, effects, etc were done in JUCE, exposed as a C API in the DLL. I didn’t even bother with any Unity audio stuff — 100% of the audio code is handled within JUCE and basic parameters are passed from JUCE to Unity and back. Within the JUCE code I had an AudioDeviceManager class that would handle connecting to the audio device internally. This was all a little while ago though — now I’d definitely use JUCE’s Unity Native Plug-In stuff.
I’ve also done a similar thing with JUCE and React Native. There can definitely be performance hits when sending data back and forth, so it takes a good app architecture to account for that.