Torn between JUCE and Qt

General JUCE discussion
1

Hi all. I’m developing a data-science sort of tool, a cross-platform desktop GUI. Right now I’m doing the core logic so I’m not touching GUI stuff yet, but I’m pondering whether to go with Qt or JUCE. I have already decided I don’t care and won’t do a native looking app. I want a custom look which I can do with both libraries equally well.

My question is which one to pick? Have you been in the same situation where you had to pick one over the other and decided one was better? The app will be mostly a node based flow, with a property panel to tweak some of those nodes, plus a configuration dialog with the usual widgets.

2

I haven’t used QT in years, but I recall disliking having to use the IDL (moc) compiler. of course, now I use Projucer without complaining, so maybe I was just whining with QT. lol…

3

My super general 2c is that JUCE is great until you need animated components, at which point the way it renders can really start to hammer the cpu. If you have constantly moving parts, maybe look elsewhere. If it’s largely static, I really like the juce graphics API.

4

I have a fair bit of experience with both JUCE and Qt. I’ve worked with JUCE since 2005. I worked with Qt from about 2008 to 2015. I still maintain one Qt app, but just do the minimum to keep it working so I’m not too familiar with the latest in Qt. It is a QWidgets based app, I am not familiar with QML at all.

I think JUCE is really good for Plugins. It abstracts away all the differences between AU/VST/AAX etc which is a huge amount of work. It also handles keeping projects in sync between mac, Windows, Linux, 32 bit, 64 bit, all the plugin formats. That could probably be 16 or more targets to keep updated, which you can now do from one jucer file. It’s also good for completely custom UIs that plugins tend to have have.

The Qt team seems quiet slow to react, the latest stable release of Qt Creator still doesn’t support Apple Silicon. Qt being from the 90s has a dated coding style, and everything must be done the Qt way. I do not like that all the QWidgets must be created on the heap and then the parent widget manages lifetime. The moc wasn’t a big deal on Windows, it integrated into Visual Studio nicely. But on macOS it meant using Qt Creator instead of Xcode. I am just upgrading to Qt 6 now, I noticed they have deprecated a lot of their algorithms, and not recommend using std instead.

The biggest downside of JUCE is the quality of the widgets. They aren’t usable out of the box, lots of features are missing or non standard. It means pretty much subclassing everything. Buttons can’t be triggered by spacebar, which is the standard hotkey. Sliders don’t respond to key presses at all. Listbox isn’t even usable without subclassing. Most components don’t disable when setEnabled(false) is called on them. ComboBox, TreeView, Viewport, ListBox, and Scrollbar all still respond to keyboard or mouse events when disabled. Expect to spend a lot of time to get components to respond the way users expect them to.

Laying out components is a complete pain, the visual editor in Projucer has been deprecated and was never very good any. The Qt resource editor is much better, and their layout system works well adapting to to different platforms with different size buttons.

If you expect your application to have a significant number of dialog boxes, go with Qt – the time you save will be huge, from laying out components to not having to spend time tweaking the behaviour of components.

Qt is also much more thoroughly tested. Downsides is it is large, I was using the LGPL version, which meant I needed to ship DLLs instead of static linking, so expect to ship many megabytes of DLLs.

If your app is going to be all custom widgets, then the differences between them are pretty minimal. But do you want to deal with custom menus as well? A lot of this depends on your market fit and what your users expect.

16 Likes
5

From your description it’s a little hard to understand what is your target or what capabilities you need.

IIUC, you have your backend pretty much in pure cpp. So it’s mostly a matter of front end for users.

If you have no advantage for JUCE DSP / audio features, why is it needed to be scoped for Qt/JUCE?

Another missing part in the puzzle is price. Unless GPLed, for commercial usage juce is I a different price range iiuc.

If front end can be separated you have much possibilities.

1 Like
6

There are certain things Juce does not include you might need for a desktop app. The first thing that comes to my mind is printing and/or pdf export, and qt certainly can deal with that.
If you need to do things audio applications usually do not do, Juce is not the best fit.

2 Likes
7

Yes, and i decided to use JUCE. Notice that at that time i had some experiences with JUCE and none with Qt. Even if the core of my app is wrote in pure C, the GUI with JUCE was for me the better choice. It is small. It is all included in compilation process, thus easy to debug, change, and understand what’s going on under the hood. The community is pretty nice. The license scheme is rather friendly for FLOSS. But as a long time user of Max/MSP probably that my POV is biased.

1 Like
8

Thank you to all of you who took the time to reply. I think I’ll go with Qt. I really like that JUCE is very small and the codebase is much neater and modern. Qt is a pig in that regard. But while I want a custom UI, I don’t want to have to implement a lot of widget functionality, just the looks.

9

When comes to pdf export, I managed to use libharu library to export pdf’s directly from JUCE applications. It would be nice to have a pdf wrapper in JUCE but I understand it is not of high priority.

I think @RolandMR said almost everything what was needed to say. I want to repeat again that even some basic but modern GUI editor would be a very helpful thing. Maybe it should be the way @daniel already started with his GUI editor for plugins? Or maybe the already deprecated GUI editor in Projucer should be reanimated with added options for screen scaling / layouts / grids / flex boxes? There were already discussions on the forum what can be improved. Preparing GUI layout is not hard but is very time consuming when done manually in JUCE, especially if you have to prepare similar interfaces but with slight but important differences for mobile, standalone and embedded systems.

But even if JUCE components lacks some out of the box features I like them better than heavy Qt widgets. It always possible to modify or subclass JUCE components one way or another.

Another issue are embedded systems based on Linux. Qt has one big advantage over JUCE: there is no dependency on X11. Qt can render for example directly to a framebuffer on Yocto Linux on iMX and Analog Devices SHARC based platforms. In case of JUCE - if I understand it correctly - it would require to implement system specific ComponentPeer. I wrote a commercial application for iMX 6 fully in JUCE and X11 but dependency on X11 is not needed at all in such cases. Personally I don’t want to use Qt on embedded systems due to their (Qt’s) strange licensing model.

1 Like
10

Jus my 2 cents…

I’ve always been very glad to have the GUI Editor in the Projucer for creating components and dialogs and even component hierarchies, and would hate to see it go TBH. I’m still able to use it just fine by the way in Juce 6.1.1 by enabling it in the Projucer, and truly hope it remains like that for some time…
Unless there is now already a better alternative that allows us to quickly drag some standard components together and style them a little bit?

For me, if there would be another “features poll” for Juce, my no.1 vote would go to:

  • either updating and continuing the work on the existing GUI Editor
  • or just maintaining the current one for now, while a new GUI Editor is created (maybe with an easy way to setup / style some associated LookAndFeel class)
11

I often thought that widgets and LnF should be rewritten from scratch but…

2 Likes
12

This was in response to the slider class though if you read the whole thread. It wasn’t about the LookAndFeels.

1 Like
13

I read again the linked thread and i still think that it is about LnF. I must be dumb. :crazy_face:

1 Like
14

No, you are right, my bad. I mixed that up with another post where jules was about the Slider and Pimpl monster.

My idea was also that a company would implement their own LookAndFeel according to their corporate identity. But many folks save the money for a designer :wink:

2 Likes
15

I don’t like how widgets are nested. If you change the Label’s LnF for instance, it changes it also when used as an element inside another Widget. Prototype is made easy, but less if you want something more customized.There’s workarounds and tricks. But IMHO that result to painfull design process (for a company or a one-man project also). Notice that it didn’t make me change my mind ; i still like JUCE. We just have to improve it!

16

I agree that some of the GUI stuff in JUCE would benefit from a big rework, but that’s just not going to happen. It’d be waaayyy too many breaking changes that would take hundreds of hours to fix for any large project using JUCE.

1 Like
17

Hi Folks,

Here are my 2 cents - I’ve used both JUCE and Qt for heavy-duty C++ app development.

And, as it so happens, I’ve recently been doing some consultancy recently for a company, to create a new cross-platform app for them in C++.

I suggested JUCE, but they wanted me to go with Qt - the main reason seems to be that the other devs there knew of Qt; JUCE seemed to be too much of a leap for them; go figure.

Anyhow: I’ve found Qt to be a real pain compared to JUCE - and the documentation is horrendous.

Major benefits of JUCE as I see them:

  • my general experience is that code is easier to write in JUCE, and tends to look “better” than with Qt
  • I find packaging-up JUCE apps much much much easier than with Qt and all it’s libraries.
  • JUCE is much less expensive to license.
  • JUCE just works with your IDE; low friction to use it; I aways find Qt a pig to configure (and as for Qt Creator - yuck!)
  • I can create what I want with JUCE - and that isn’t limited to “just apps” - Qt is much more limited - for example, I have JUCE UI running embedded on tvOS…

There are things in JUCE that would benefit from improvement for sure, but that is the way with anything:

  • out of the box app for desktop that supports Menus (and some alternative for mobile) would be useful; this is always a head-scratcher as I can never track-down a concrete example - and would make it much easier for app developers to “just get started”
  • screen navigation system (mind you, Qt doesn’t have this either)

Best wishes,

Pete

10 Likes
18

Oh - and the JUCE forum is really, really helpful :slight_smile:

2 Likes
19

Funnily enough, my client has now decided they’ll change over to JUCE from Qt, as they prefer the JUCE pricing model!

2 Likes
20

I love when companies make a plan and stick with it :rofl:

2 Likes