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.
Thanks for all the sudden attention, HN readers - my website's just about surviving the onslaught! Hope some of you discover JUCE from reading this!
I'd just like to say that if anyone tries the demo app and finds it a bit tired and old-fashioned, that's because it is! We're in the middle of writing a new demo at the moment that'll show off a lot more of the library's cool features in a slick way, but it won't be ready for a couple of weeks. (Ideally I'd have waited until that was ready before getting HN'ed, but am still grateful for the hits!)
Cool to see you here Jules. I used Tracktion from around 2003-2008 and loved it. Always thought the UI was nice and I was excited when I found out about Juce. Whenever I get around to learning some DSP I'll use it to make plugins :)
Thanks! Actually, one of my big tasks over the next few months will be to redesign Tracktion's UI and try to make it look at bit more contemporary. Quite an interesting challenge!
I worked at an audio company previously, and one of my main jobs was porting a large acoustic simulation suite from Juce to Qt (EAW Resolution).
Unless you really need the audio specific features that Juce includes (we didn't as we did everything in-house) there's really no point to using it.
Qt has a bigger community, more extensive (and IMO more well thought out) libraries, and as has already been mentioned, a native look and feel that can't be beat. Not to mention, Qt is completely free for personal and commercial use.
The only popular commercial app I know of that is using Juce is Smaart by rational acoustics. They used MFC before that if I recall, so obviously the cross-platform capabilities are a huge bonus. I still wondered why they didn't move to Qt like us though.
Oddly, I love everything about this except the Introjuicer, which basically Yet Another XML Based Build Tool.
Quote from the author:
When I first decided to build the introjucer, my first
approach was also to use cmake, but on investigating,
it really was far simpler to just cut out the
middle-man.
Dang~
Looks like I won't be using it after all; nothing I love less than learning new build systems.
I've used JUCE professionally for almost 2 years now and I find the introjucer to be a very poor substitute for CMake.
It is all GUI based and hardwired to a single XML file with predefined settings, so there just is not a lot of flexibility for setting up more complex projects nor sharing settings across projects.
Even the things that introjucer does support, it does not always do well, like icon support or keeping up with the latest iOS changes to Xcode for instance.
The general problem with JUCE is that is just a too ambitious project for one man and feels like a "well executed hobby" library instead of a "professional production" library. There are a lot of inconsistencies and bugs that you quickly run into when you dig deep enough into the library.
Issues are fixed and introduced on a daily basis, you have to be very careful when updating the latest "release" (which seem quite random) as your existing code could break.
That being said, I think the price for a commercial license of JUCE is a steal if you are working with C++ audio/DSP programming and it will save you a lot of time up front.
You just have to keep in mind that you will probably need to invest time in patching/extending JUCE due to the fact that only one guy is maintaining it and he only has so much time to work on it every day.
Well, I designed it to make my own life easier, and if it's useful to other people, then great! Personally I couldn't live without it now, it saves me a huge amount of time in managing projects, but obviously people's mileage will vary..
But something thing about the design of the codebase is that it doesn't need a fancy build system - you can include everything in a project by just compiling a handful of cpps that wrap up all the code into module-sized chunks, so if you do want to use juce in some other tool, it should be very easy to do.
yeah, i dislike the introjucer too. however, you usually need it precisely once to set up the initial projects for each platform. after that, i never touch the introjucer again but manage my projects by hand.
I looked into this for an audio app, and it looked really cool. Then I contacted him to find out what contingencies were in place because of the truck number of 1 (!!). I asked him if he had any business partner, or perhaps a dead man's agreement in place in the license by which if the company folded or he left it would revert to open source. Not only does he not, but he was a jerk about it, completely dismissive of it as a valid concern. No way would I put years of work into a project on a platform that might become stagnant because of his lack of foresight or understanding there. So I just used QT and other audio only toolkits. Pity, it's really neat looking.
Well, that's the beauty of open-source... I try to be hit as few trucks as possible, but it certainly wouldn't mean the end of the project, just perhaps a slight drop in code-quality :)
I remember you getting in touch and asking about this because I think you're the only person who ever asked me about the truck-number. Slightly surprising, really - I've sold licenses to all kinds of huge mega-corporations who I would have expected to worry about such things, but apparently not. Just you!
..actually, I should mention that although most of the library is still GPL, the core module is now under a permissive ISC license. So if you're doing non-GUI or audio stuff, you can use many of the core classes for free.
Jules I am a real fan of your work, you are an inspiration - thanks for your response! Reading iain's comment again - I think he knows it is GPL already but for commercial users he's concerned that they would have to GPL their code to get updates if something unfortunate were to happen.
I've been using JUCE for a couple of years for VST development. I've found it to be a very well put together library for audio work (diving straight into Steinberg's SDK is pretty daunting for someone new to audio like myself), and a lot just works out of the box.
There is strong leadership from Jules on the direction of the library which is generally a very good thing, though it does mean that sometimes there isn't much room to budge on controversial issues. Font rendering is one aspect that several have battled with for a while, I've struggled to get good crisp smaller fonts without resorting to using freetype. Jules argument seems to be that small fonts shouldn't be used period, therefore the library wont render them well (I think there are technical as well as philosophical reasons for this, particularly on OSX). While I agree they should generally be avoided, there are certain situations where this isn't the case (reproducing an exiting GUI for a client, fitting non-critical text in when screen real estate is at a premium etc).
Overall I would certainly recommend for anyone starting out in audio development, but be prepared to fiddle around with fonts; I'm not so familiar with the non-audio parts of the library.
Looks interesting, I come from a Qt background so cross-platform toolkits always have a bit of interest for me. It does seem like it's definitely for people building highly customised interfaces, rather than looking for OS-based look and feel but there's some nice bits. I think I'll give it a whirl when I've got time for a side project.
We use Qt at work for one of the big projects, and we are very happy. That to be said, juce is small, embeddable (your executable can be around ~600kb on windows), and while you can statically link to Qt it's still bigger, and some things don't work right (plugins).
Looking at it quickly, you should use JUCE over Qt if you're building a custom UI from scratch and you want a lot of multimedia help, you should use Qt if you're building a more traditional desktop application.
Fair point, both you and malkia. I'm C99/C11 guy though, but always resort to Qt for frontends. I wish we had more (any) C only solutions out there. Yeah, I know..Glib...sigh.
We "were" in the same boat: our company decided to build UIs using C# and leaving the hardcore modules to C/C++, interfacing them via COM. Developing UI interfaces in C++ under Windows is a pain in the ass.
An example of this is our SpyStudio product[1], which was developed in C# using our Deviare technology[2] for instrumenting binary applications.
We had a legacy application using MFC/C++ and no one anymore likes MFC at the studio, so we had to either somehow switch to C#/Windows.Forms|WPF overnight or slowly move to something else. Since there is MfcMigration toolkit for Qt - slow progress was the choice - so every week less and less of MFC is visible, and more and more from Qt.
Other toolkits can benefit if there is a transition layer - or at least something where you can plug into the existing message pipeline, windowing system - and then start replacing widget by widget, dialog by dialog.
I like how all the examples look like VST plugins. Seems that the horror that is VST GUI paid off, because it triggered someone to do better! (note: that's a completely uninformed guess)
I didn't know about this though, and will definitely consider it if I'm ever bound to C++ again.
I especially like how iOS and Android are targets. Easy to code, highly customizable, fast/native, cross platform mobile apps? Yes please! Sure, Qt can do all this too, but I suspect that many app designs might fit the "audio plugin" UI design attitude better. Especially if you have a designer who likes to .psd every single control.
Kind of weird how he wrote his own string class, as well as rewriting some other perfectly good standard library stuff.
His version of scoped_ptr seems to fake rvalue references without actually using rvalue references, but does so in a copy constructor. IMO this is a bit bonkers. If you're not going to use rvalue references I think move semantics is better done from a method, not a copy constructor.
Still looks like a handy library for wrapping things that are otherwise not portable.
Edit: I was mainly basing that comment from looking at juice_core... There's a crapton of other stuff too. Impressive for a one-person work.
Ok, the reasons are/were:
1. Back in 2001-ish, Java was cool, and I was copying the java string class.
2. I wanted more functionality than std::string offers. Yes, yes, I know all the arguments about keeping the class simple and using external methods for adding functionality, and I generally agree with that philosophy, but having used both juce::String and std::string, in practice the juce design just seemed to result in cleaner code.
3. I wanted it to be able to easily cast to utf-16 or 32, and std::string was a bit clunky for that.
4. It's a long time ago, but I vaguely remember std::string having performance issues on some platforms.. Can't remember the details, but there were definitely problems that made it perform differently on different compilers.
If I was designing a string class today with hindsight, I'd probably still go for the overall design of juce::String, maybe tweaking some of the methods a bit, but I might make it wrap a std::string so that they can be interchanged efficiently.
He started working on it 2001/2002, at that time, C++ implementations of the standard library were poor and inconsistent across compilers. There is a reason that pretty much every library from that era redid all the basic classes - Qt, MFC, etc. When I learnt C++ it didn't have std::string.
I find QByteArray and QString more useful and complete than std::string, yet we keep our interfaces to std::string or const char*, since this would reduce external dependencies for other folks that want to use the library (also the learning process, and less include files).
Kind of weird how he wrote his own string class, as well as rewriting some other perfectly good standard library stuff.
not that weird: Qt and others do it as well. Not sure why though, maybe because at the time they started there was a lack of a decent std::string implementation on all platforms?
Qt does it because the library predates common availability of std::string across multiple compilers. It's been a while since I looked but there is a lot of funky stuff in Qt that would look saner if they had the benefit of starting with a recent standard.
So build unicode routines on top. Don't make me put all my data in a non-standard datatype where another type already exists and is more common.
Users of C++ already have to deal with std::string and char * and possibly PWSTR if they are on Windows, why throw yet another type at them?
This reminds me of a joke I used to tell, it starts with a problem that there are too many string types, and the solution, somehow, always ends up being another string type...
According to the About JUCE page the license is GPL, so you need a commercial license if you want to use it in a non-GPL project. The pricing doesn't look too bad if the library is solid (£399 for a single project, £699 for unlimited).
They really need a lighter color for the text on their website -- tough to read.
I've been using JUCE for various project for about 5 years.
I really enjoy coding with it, once you understand the naming convention (which is different from everything I've used before), it's quite intuitive.
If you use the API in a wrong way, it will assert somewhere inside the library, and the assert has a nice comment above it explaining what you did wrong.
The main benefit for me is the size of the executables - no other cross-platform GUI toolkit that I've used before can end up with such tiny executable files.
QT might be more powerful, but it's HUGE and that is a problem for most of the apps that I develop.
They exist, but none of them I've run into are particularly good. I'd say that Qt is probably the least-bad, but it feels very "wrong" on OS X and only somewhat better on Windows.
@julesrms: I'm looking through the docs and can't find the answer: Do the drawing functions support anti-aliased 2d primitives (lines, circles, etc)? I'm looking for a C++ 'Canvas' type object that's requires very little code setup; just let me open a window and give me an anti-aliased drawing surface. Could JUCE help me with that?
Thanks, I'll take a closer look then. How do you think it would handle with rendering massive images for canvas printing, like, say 3'x2'@300dpi or bigger pixels?
Yeah, I'm sure that'd work fine. The Image class itself doesn't have any size limits. I guess that the openGL engine might hit GPU limits on texture size, but the software renderer should handle anything you throw at it.
I think one of the reasons Jon manages to pull it off so well is how basic it is. He has a 100% custom sidebar (very basic), but other than that he is using native menu controls and standard dialogs. Obviously the editor pane is the big custom component.
That's a good point. I think one of the reasons Sublime works so well is because the interaction is minimal and unobtrusive. You don't realise how simple the controls are - as you said; standard dialogs etc.
I'm developing professional audio and 3d tools. In these areas, people expect a GUI that ignores native styles and looks identical cross-platform. That is precisely where juce excels.
The Lisa had the Application Toolkit, which was a shared library written in Clascal (predecessor to Object Pascal) that had all of the basic behaviors of an application.
Then the Macintosh had its function library, called the Toolbox. That's where a great many people heard the term. (The Mac didn't have a framework, though it did get MacApp later - which was similar in design to the Application Toolkit and originally written in Object Pascal.)
I looked at Juce a while a go when researching native GUI libraries and ended up choosing QT, but seeing that resolume uses Juce I might have another look at it.
Juce is an incredible framework, jules is also a great guy, he implements stuff daily that the community requests. It makes creating C++ stuff even fun !
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.