5 ms·

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

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.

deleted 13y ago
[deleted]
vinkelhake 13y ago
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.
- logn 13y ago
  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. Here's an example UI showing my point (and the app Juce was spun out of) http://www.tracktion.com/ http://www.tracktion.com/
malkia 13y ago
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/ http://www.tracktion.com/
- FigBug 13y ago
  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.
  - skrebbel 13y ago
    > 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.
    - FigBug 13y ago
      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.
wslh 13y ago
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.
JabavuAdams 13y ago
In-house or multimedia tool development.
zokier 13y ago
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 13y ago
  > 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.
  - sillysaurus2 13y ago
    Actually, the ribbon UI was a great success.
    - icefox 13y ago
      Based upon what? Outside of office I don't know of any app that uses it or something similar.
      - skrebbel 13y ago
        How about, eh, all of Windows? 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.
julesrms 13y ago
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).

deleted 13y ago

[deleted]

vinkelhake 13y ago

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.

logn 13y ago
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. Here's an example UI showing my point (and the app Juce was spun out of) http://www.tracktion.com/ http://www.tracktion.com/

malkia 13y ago

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/ http://www.tracktion.com/

FigBug 13y ago
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.
- skrebbel 13y ago
  > 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.
  - FigBug 13y ago
    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.

wslh 13y ago

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.

JabavuAdams 13y ago

In-house or multimedia tool development.

zokier 13y ago

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 13y ago
> 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.
- sillysaurus2 13y ago
  Actually, the ribbon UI was a great success.
  - icefox 13y ago
    Based upon what? Outside of office I don't know of any app that uses it or something similar.
    - skrebbel 13y ago
      How about, eh, all of Windows? 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.

julesrms 13y ago

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