Naturally this is a JUCE forum so you’re only really going to get validation for using JUCE rather than Qt.
All the benefits of JUCE have been mentioned already and it’s an amazing library, and really the only game in town for cross platform audio.
Qt on the other hand really is a different proposition, it’s an older, swiss army knife with a large amount of features. The killer feature for me in Qt is QML I can make a beautiful animated (whilst hardware accelerated and extremely performant) UI in a few hours, and the same would take me days in JUCE. The JUCE UI framework is comparable to Qt Widgets. Legacy in my opinion.
So we went ahead and used Qt QML for UI and JUCE for audio. Why not?
Here’s a talk with a quick description of our architecture:
Here’s what our latest product looks like - the UI was implemented in a couple of months:
Best of all worlds. If you need good audio stuff, you must use JUCE. If you want powerful UI development, go Qt. If you need both, get both! Whilst Qt commercial is crazy expensive, if you can’t afford Qt, you can comply with the LGPL license and release for free, even commercially. JUCE is GPL or commercial, so if you’re selling you have no choice but to pay. But JUCE is worth paying for.
We do have the OpenGL module but IME it’s just not a realistic option for larger projects. There’s lots of talk around adding a more modern alternative although no indication of when such a thing would be available - I just hope we have it before we need it, otherwise we’ll have no choice but to migrate to another GUI library.
We do use Qt for some projects, but we seem to be trending towards only using JUCE. At the same time our designers are trending towards wanting more complex UIs, it’d be a real shame (IMO) if we had to resort back to Qt again to accommodate for this.
I am working on a bigger project that is done in QT and I am replacing the playback engine with JUCE. It is perfectly doable to mix, but requires a bit of understanding of build setups and devops, as well as an understanding of how modern GUI frameworks are working. There are many similarities between JUCE and QT.
For a PlugIn I would try not to bring in too many different frameworks, since you have to consider the GUI message loop is shared between JUCE and the host already. I think it gets even more complicated if you bring in the message loop of QT on top.
For any fancy GUI and great looking components, you will likely be disappointed by both. QT has a lot of tools for layout/placement of components. But they also look a bit like the 90s.
Graphics hardware will always be a weak spot of any abstraction of plugin frameworks, since the process doesn’t use the GPU exclusively, but has to share with the host and all the other plugins. That’s why I prefer to abstain from glow, particles and all those fancy GPU heavy stuff and draw simple things instead. It works well for me, and doing shadows with gradients works just as nice without GPU and gives good depth as well.
But yes, here is some room for improvement for JUCE in terms of hardware graphics. For me personally it is good enough to outweigh the pain from mixing with other frameworks.
For those struggling with Qt Layouts - I’ve found that for Qt (C++) layouts - the built-in ones never worked as I wanted.
So, I just do all the layouts dynamically, which is easy once you realise you just have to create your own variant of QLayout - I created a very simple one which just uses a lamba, calling back to a method that can do the layout basically how I handle it in juce::resized(…)
This is getting slightly OT, but since you mention Qt layouts, my first action when starting with juce was to create QT style layouts (I don’t recommend that project, but FTR it’s here).
Moving on I learned about FlexBox and CSS, so I created PluginGuiMagic, which makes JUCE pretty much on par with QT in terms of convenient layout and styling IMHO.
