
Juce: An extensive, mature, cross-platform C++ toolkit - wslh
http://www.juce.com/
======
shaggyfrog
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.

~~~
zokier
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.

~~~
hyperbovine
> 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.

~~~
zokier
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.

~~~
hyperbovine
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.

~~~
cookiecaper
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.

------
julesrms
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!)

~~~
blt
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
:)

~~~
julesrms
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!

------
seabrookmx
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.

------
shadowmint
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.

~~~
lukaszdk
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.

[https://github.com/julianstorer/JUCE/commits/master](https://github.com/julianstorer/JUCE/commits/master)

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.

------
iainduncan
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.

~~~
eliasmacpherson
Correct me if I'm wrong - but there was commercial and GPL licences, are the
GPL licences gone?

~~~
julesrms
No.. it's still GPL.

~~~
eliasmacpherson
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.

------
hemmer
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.

------
nicholassmith
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.

~~~
Keyframe
My first thought, as well, was why should I use JUCE over Qt. Especially
considering license. I'll have to look more carefully through code.

~~~
nicholassmith
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.

~~~
dkersten
I'm not sure if this is really true if you use Qt 5 and Qt Quick, which allows
you incredible control over the look of your application.

------
skrebbel
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.

~~~
foxhill
if i never have to use VST GUI again, that wont be long enough.

honestly i think steinberg were pushing for using native widgets. i'm confused
then, as to why the native UI system looks just.. terrible.

------
asveikau
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.

~~~
stinos
_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?

~~~
zokier
std::string is very low-level interface, and has eg. very little to no
provisions for Unicode.

~~~
asveikau
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...

------
Bill_Dimm
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.

------
codeboost
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.

So great work Jules and do give it a try!

------
wbond
I realize this may be slightly off-topic, but is there something like this
that focuses on building cross-platform apps that have native UIs?

I've obviously seen wxWidgets, but I'd even be interested in commercial
offerings.

~~~
eropple
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.

------
samograd
@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?

~~~
julesrms
Yep, tons of anti-aliased 2D stuff, using either a 100% software renderer,
CoreGraphics, or an openGL shader based renderer.

~~~
samograd
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?

~~~
julesrms
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.

------
jbrooksuk
This makes me wish that the developer of Sublime Text would release his UI
toolkit. It's completely cross platform too.

~~~
wbond
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.

~~~
qznc
Sounds like Scintilla [http://www.scintilla.org/](http://www.scintilla.org/)

~~~
jbrooksuk
I used Scintilla a lot when working with AutoIt [1] - it's what powers their
standard IDE, SCiTE. It's okay. But not nearly as powerful as Sublime.

We've started packaging Sublime config files into the installation too now. (I
say we, I'm an MVP).

[1] [http://autoitscript.com](http://autoitscript.com)

------
p0nce
Juce is great especially for audio plugin developers, an alternative in this
area is WDL-ol. [https://github.com/olilarkin/wdl-
ol](https://github.com/olilarkin/wdl-ol)

------
fxtentacle
been using it for years, its brilliant :)

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.

------
pekk
How did "toolkit" come to mean "GUI library"?

~~~
eschaton
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.)

------
corysama
The editor in Juce apparently features C++ live-editing/hot-reloading
[http://youtu.be/imkVkRg-geI](http://youtu.be/imkVkRg-geI)

~~~
julesrms
Yes, but sadly still not yet released, due to me having absolutely no time to
work on it :(

(Anyone who finds the Projucer project interesting and who might be interested
in throwing some resources at it, please get in touch!)

------
yeureka
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.

------
samograd
I think I see the insides of a Lisp hiding inside ;-)

    
    
       http://www.juce.com/documentation/tutorials/valuetree-class

------
fbomb
All it needs is a spellchecker ;-)

------
sambecket
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
!

