[qppo]

The DSP module in JUCE isn't production quality, and the audio I/O integration in RtAudio is good enough for even professional use cases.

JUCE is really painful to use if you want to integrate it into anything modern. It's old, it's slow, and you really can't make it better. I really can't express how much distaste I have for JUCE after shipping multiple products built on it - it solves _one_ hard problem (wrapping AU, AAX, and VST3), other than that it is dog slow and can't be improved because the core devs don't accept outside contribution for no reason except their own hubris.

Any cross platform UI in C++ that isn't JUCE or Qt is highly welcome. Especially one that allows me to pull in external dependencies and use modern build systems, test frameworks, CI/CD, and other tooling.

[merlinsbrain]

I have been playing with Dear Imgui lately, and while its super easy to get up and running, I realized it doesn't have support for zoom (cmd +) and accessibility (unless I missed something).

It seems like those features are out of scope for the library - which is fair, one has to draw the line somewhere, and there are enough success stories with the project that it may not matter to a lot of the people. The author has mentioned in various places it's mostly for internal tools or game dev, which makes sense.

I am glad more toolkits are coming up (both for C/++ and Go, the languages I am interested in writing desktop apps with), but I am a bit surprised Qt seems by _far_ most mature compared to a lot of newer tools, not counting wxWidgets or glade/gtk3.

[qppo]

Very few C++ UI frameworks deal with accessibility or platform UX standards like zoom (ctrl +). You have to use platform/native APIs directly, or frameworks that seek to model them (which usually are not native).

It's not unsurprising to me that Qt is the most mature. It's the oldest, most widely used, and probably the most well financed...

[merlinsbrain]

Also, I can really see the appeal of electron now (from a development standpoint).

It really is Qt vs Electron if you want to ship a product that makes money - something I am paying for is expected to have a lot of these "features".

[merlinsbrain]

Yeah, I guess the key is the last part of your last sentence, heh

> the most well financed..

[bsenftner]

I suggest looking at wxWidgets. Fully cross platform, no commercial/paid version, all open source, without any of the org issues facing QT, and it's... a classic GUI.

I'm interested in seeing if Elements can integrate. WxWidgets has the typical amount of code (more than a little, but not much more) to create one's GUI. There's significantly more than just a GUI, BTW.

I also tried Dear Imgui, but had to back out due to the constant rendering requirement of Imgui, because my applications are already hi-compute and a persistent GUI is required when you're already pushing the CPU without any GUI.

[brnt]

What's wrong with Qt? I really like it.

[Kliment]

Qt is lovely but the company that controls it is in a bad place financially and it's not clear what will become of Qt if they go under. There's also the issue where if you get a commercial Qt license it's much more difficult to contribute to Qt under GPL or LGPL. And of course the license is tremendously expensive unless you're making serious money with the application, so prohibitive to smaller companies. I love Qt but I would never feel comfortable using it in a commercial project. There was also this bullshit earlier this year where they tried to pressure KDE into worse terms https://mail.kde.org/pipermail/kde-community/2020q2/006098.h...

[sdwisely]

> Qt is lovely but the company that controls it is in a bad place financially and it's not clear what will become of Qt if they go under.

this part has always been clear:

"Should The Qt Company discontinue the development of the Qt Free Edition under the required licenses, then the Foundation has the right to release Qt under a BSD-style license or under other open source licenses. The agreements stay valid in case of a buy-out, a merger or bankruptcy."

https://kde.org/community/whatiskde/kdefreeqtfoundation.php

[Kliment]

Yep, but a hostile entity that owns Qt can do a lot of damage to Qt by publishing on the last permitted day, and denying community contributions and destroying community governance. I can definitely imagine a hostile corporation like Oracle doing so (and they have form).

[brnt]

Qt is still available as GPL. Even if the Qt company goes under today and nobody picks up development, it's stil a great package for many years to come.

I agree behavior lately is not great, and a Qt company in trouble won't be good, but I think the community will pick up quite a bit if it comes to that.

I also think many misunderstand or misrepresent the implications of a GPL only Qt (for closed source applications). It's a matter of linking correctly: https://news.ycombinator.com/item?id=23321448

[Kliment]

Right, of course it is, but if the Qt company goes under the highest risk is that its assets get purchased by a hostile entity, which releases everything with a year's delay and doesn't allow community governance/contributions. Imagine Qt owned by Oracle and you'll understand my concern. Of course if that happens KDE and the other current Qt users will likely fork it, but someone like Oracle can do a shitton of damage to the community in the process by threatening litigation.

The issue with the commercial licensing is that if you are a commercial licensee you are contractually prevented from contributing to Qt in some ways. See https://www.qt.io/terms-conditions/ and search for "Prohibited combination". If you are able to comply with the GPL or LGPL components without becoming a licensee, this is better in every way (you get to contribute, you have much more legal safety if the company gets acquired by a hostile entity, you don't have to worry about what happens when your license expires, and of course you save money). So those license terms are actively preventing the Qt company from getting revenue, because you get a worse deal in most ways if you pay them than if you don't. This is why I'm uncomfortable with Qt in non-GPL/LGPL commercial projects. You get trapped and you can't relicense your project to GPL afterwards even if you want to.

[AshamedCaptain]

I really dont get why people still throw FUD with this argument. It's been what, 25 years already since this argument lead to the KDE Free Qt agreement?

At this point the biggest concern for the Trolls (or whoever owns Qt nowadays now) should be that the FUD against GPL is starting to slowly evaporate, so even big companies are starting to use GPLd Qt rather than pay licenses. By the time they go Oracle there will not be much they can do.

[vmsp]

Have you tried the latest version of JUCE? I think it supports cmake now.

[wheels]

I've actually been using JUCE with CMake for ages using this project:

https://github.com/McMartin/FRUT

It's meant to convert Projucer to CMake files, but we just create them ourselves. The CMakeLists files come out a bit wonky, but it works.

[qppo]

I did briefly. The CMake integration is... quite strange. It kind of has to be because of how strange the compilation model is for a JUCE project, where all your includes depend on having the same set of preprocessor definitions.

[nunja]

I switched to Juce 6 preview branch last week. It's not without problems but getting rid of the Projucer is amazing. Now you can have a clean CMake setup and you are not stuck with Xcode on the mac.