A former client of mine considered Juce for a cross-platform project several years ago. It seems to be popular in the the audio programming segment. The biggest drawback is the lack of native look-and-feel; Juce apps don't "feel" native, and that's usually enough to keep it an also-ran for most use cases.
I don't really see the big advantage for these cross-plaform GUI frameworks, anyway. Trying to force a standard interface across diverse platforms means coming up with odd idioms or patterns to achieve a kind of artificial homogeneity. Better to concentrate effort on making the business logic cross-platform, IMO.
The main reason I never added a native-widget implementation to juce is actually just lack of demand! It was very rarely requested, so was never a priority.
That might just reflect the kind of crowd who use juce, but I do think that native widgets are getting less important these days, as people become more and more accustomed to website UIs where every site has its own style.
Also, back when I started all this, semi-transparent HWND child windows weren't possible on Windows 2000/XP, and early OSX versions also struggled with this. The stuff I was building at the time needed a lot of semi-transparent graphics, so the best approach was simply to render the entire GUI in software and not be limited to what the OS offers. (And for many situations that still makes sense).
Nativity in UIs is over-rated imho. Tons of apps I'm regularly using do not have native UIs and still fare quite well. Heck, I'm not even sure what the native toolkit for my platform (Windows 7) would be. I guess WPF would be the closest thing?
Most notorious example would be Microsoft Office which afaik never has used native widgets, being always one step ahead of Windows UI design. Other examples out of my head are the whole Adobe suite (which is arguably a mess UI wise), both Firefox and Chrome, Spotify, Steam, Blender. iirc the Open/LibreOffice widgets are custom too. And of course GIMP has its own toolkit, even if it is spread bit beyond GIMP itself.
Actually the last few iterations of VS and Office skinning have gotten added into MFC and can be enabled pretty easily for any app. The Ribbon UI is also fully available in MFC and VS. Just no one uses any of this stuff for obvious reasons.
Spotify actually uses Qt but with a custom stylesheet that makes it look more like iTunes. I have no idea why they did this, I think it makes it look terrible and clunky. Read this for more info:
> Most notorious example would be Microsoft Office which afaik never has used native widgets, being always one step ahead of Windows UI design.
And yet when Office switched to the ribbons interface, all hell broke loose. The moral being, people hate having to learn a new UI. Consistency matters.
But that is almost completely orthogonal to the issue of nativity. That is demonstrated by the fact that Office wasn't using native widgets before ribbon either and people were happy, and as a counter-example Metro/ModernUI is arguably the native UI for Windows 8 and that hasn't stopped people from disliking it.
Exactly--people were happy with the old UI, which, non-standard or not, was in place for ~ a decade. They really resented having to learn something new. Now repeat that experience once for every new application you want to use. It can be extremely frustrating.
The point is that "UI nativity" means things like "checkmarks in checkboxes should appear in the same way across all applications". It's pretty easy to distinguish a checkmark in a checkbox no matter what platform you're on, and real users don't care if it matches the rest of the platform exactly or not.
"UI nativity" is basically a way for design snobs to feel like they're making a contribution by whining about something trivial and irrelevant. A normal person can still recognize the meaning and doesn't care if the checkbox is beveled differently from app to app, and anyone who discards an application on such minor inconsistencies is not doing serious work anyway, and should be disregarded.
I've seen at least a bunch of non-MS apps that use the ribbon. Spoon Studio, a tool for containerizing Windows applications, is one that I used recently. There's more, but I can't come up with them.
I think it's a very powerful paradigm. Compared to LibreOffice's "toolbar overkill", it's surely a step forward. Making a large amount of operations in a simple way is always difficult, the ribbon seems a least-bad option compromise, that works quite well.
From the screenshots it looks like this toolkit is meant to be used in applications where a non-standard interface is the standard. For some reason this seems to be the case in a lot of audio applications.
Audio apps tend to need to have special UIs and widgets which aren't typical needs for most apps. You need special sliders, drawing tools, and color schemes for live performance that aren't baked into many widget toolkits. Even if they are, you're dealing on such microscopic levels of detail on these UIs that you really do want them to be the same pixel-for-pixel on any machine. And if you're selling a cross-platform audio plugin to musicians for a couple hundred dollars for the last 5 years, it's nice to totally remove OS-specific UI weirdness from the equation.
Juce apps don't "feel" native, and that's usually enough to keep it an also-ran for most use cases.
I experience the reverse, customers are asking us all the time for adding non-standard custom draw GUIs. I found that doing non standard UIs we can also charge more for the risks involved.
That's true, but if you are plugin developer and your platform (audio, 3d, etc.) is already cross platform (linux, osx, windows) then getting the same look&feel might be your priority - e.g. if there are knobs, switches - especially found in audio plugins - it'll be very good to have the same interface (few exceptions) everywhere.
I also understand the need to use native, or look-like native widgets where possible, but juce started (from what I know) as project isolated from Tracktion which ran on osx, linux, windows, etc - http://www.tracktion.com/
I was the lead Tracktion developer for a while, Jules sold Tracktion to Mackie where I worked on it. Then Mackie lost interest in it and eventually sold it back. It was my first experience with Juce comuing from an MFC/Win32 background. It's a very nice library with a clean, consistent interface.
A few of the downsides have already been mentioned, but there was one big upside in that there was an amalgamated version of the library that put the entire library into one cpp file and one header file. It made building and distributing applications so simple compared to a lot of other cross platform libraries. (Qt/wxWidgets) I used it for a lot of command line utilities (I believe the core of the library is BSD rather than GPL) Makefiles were as simple as building two cpp files. I really like C++, but getting it to build with dependencies on a bunch of platforms is usually such a pain in the ass.
I used Juce for one more major application after Tracktion, EAW Resolution (LOUD Speaker modeling), but after the first version was released the licensing model of Qt changed to LGPL and it was ported to Qt. Qt has a lot more support behind it. And while Qt isn't perfectly native, it's a lot closer. The projects I work on just don't have the budget to do separate native versions for each platform. It's usually just me, or maybe one other developer.
> A few of the downsides have already been mentioned, but there was one big upside in that there was an amalgamated version of the library that put the entire library into one cpp file and one header file. It made building and distributing applications so simple compared to a lot of other cross platform libraries.
That's a genius idea. I wish all c++ libraries have that. I can't, just off the top of my hat, see a single downside.
SQLite also has an amalgamated distribution for easier embedding.
The only gotcha I've seen with this method is when the debugger (Visual Studio in this case) can't handle more than 32768 (or was it 65536) lines. Usually the work around is to furthermore split into several, not one amalgamated versions.
Game developers love libraries coming this way, since using them right away is much easier, and often there is only one thing being shipped (the game exe).
Link times are super slow, visual studo couldn't handle debugging a file with over 64k lines. But it's wasn't a big deal, since I'd develop with the normal library and distribute with the amalgated library. Juce seems to have gone away from the amalgated system for the entire library, and instead each module (core GUI etc) use a similar system. Not quite as slick anymore.
SQLite has had this capability for about 10 years. It's also be the default distribution, those most embedders I know choose to rebuild with the configuration options tuned the way they need them.
I don't really see the big advantage for these cross-plaform GUI frameworks, anyway. Trying to force a standard interface across diverse platforms means coming up with odd idioms or patterns to achieve a kind of artificial homogeneity. Better to concentrate effort on making the business logic cross-platform, IMO.