The problem with the native-widget control approach is that Juce’s class hierarchies deal with events radically differently than native controls do. Take a look at the APIs for menus under Windows and under Juce. https://msdn.microsoft.com/en-us/library/windows/desktop/ms646977(v=vs.85).aspx When you finish all that mapping of Juce abstractions to Win32 controls and messages, you’ll find that it would have been easier to simply paint the window with something approximating Win32 kerning and color handling yourself. Even Microsoft’s own .NET took this approach, which is why .NET’s controls are not pixel-accurate to the rest of Windows. There’s nothing magical to how native libraries draw their controls. See also https://developer.microsoft.com/en-us/windows/desktop/design .
@johnwbyrd, I’m coming at it from the perspective of having tried to recreate native UI on mobile devices with JUCE, and coming up against a wall when attempting to recreate some of the screen transitions and effects that come for free e.g. with iOS. I’m currently working on an update to an app that was written purely in JUCE that mimics iOS navigation. Even if it can get close enough in terms of “look”, a pure JUCE component cannot (IME) match the “feel” of native iOS controls which offer the user a completely smooth and seamless UI experience, even on low power devices.
On desktop environments, I can see that this would not matter so much as there is generally enough processing power available for high framerate animations.
@adamski So how would you approach using native Objective-C Coding and using the backend DSP and synthesis of Juce. I would love to do this. It’ll give me the best of both worlds.
Keeping up with the current UI fashion in an interface somehow implies to the user that the coding is stale of art. I even feel a little like I am not using the best available plugin when I use a plugin that looks like it was created ten years ago, even though my ears tell me differently. Sometimes the latest fad looks like garbage, but that is irrelevant, it feels modern in an ever changing world.
A decent UI designer could take the essence of the latest UI fashion and create a JUCE look and feel for it. I think this would increase JUCEs public appeal.
@MIDIculous
You could use Juce as a static library and just use the audio classes… that might be a simpler approach, but one that requires duplicating UI code if you decide to build for another platform.
Are you talking about an iOS or macOS app?
Ios
#if JUCE_IOS
//plain ol' iOS framework calls
#endif
@adamski, I come at it from the perspective of trying to get apps to run with native-seeming controls on PC and Mac. If a cross-platform engine with native widgets on mobile devices is of import to you, then you may want to take a look at Xamarin.
If you’re building a Max/MSP nodegraph style audio tool, it’s not immediately clear to me how much native mobile UIs will come into play, but of course you may have a deeper vision here.
Wow. This thread is still annoyingly ongoing, regardless of how old it is…
I haven’t read the other messages, and don’t really care about the chain itself, but have something to mention that is completely relevant:
If you are in such a need of wanting a native UI (not just a look and feel per platform!) with JUCE as part of your app, you can choose to painstainkingly write your own native apps one by one and embed ScopedJuceInitialiser_GUI somewhere appropriate in your application.
@johnwbyrd yes, I did look at Xamarin a few years ago when it looked expensive, I am aware they’ve since lowered the barrier of entry. I’ve been working with React Native which, although it has its quirks, and getting all the bridging in place between JUCE/C++/Objective-C/Java and the javascript side can be tricky in places, for building out the UI (with native controls if thats what you want) I’ve never come across a framework that lets me build as fast. Although I still prefer pure JUCE from a programming perspective 