Why no native ui?

I was just wondering - everyone looking for a cross platform c++ library wants to be able to use the default user interface for the target platform, i.e. a native ui.  Why doesn't JUCE provide this?  It could be done with use of wxWidgets, and then you wouldn't really even need to support it (I believe QT makes use of that, but QT is ridiculously expensive and not as powerful as what you have). 

I guess it would be possible to do the user interface in the target invironment instead of in JUCE, but that defeats the purpose.

IMO, it would be best to incorporate something like wxWidgets in your codebase, as a separate option to your ui.  That way, you would attract the user base of those already using wxWidgets, but wanting something more, like what you have put together.  I would even help you put that together if you like.  I have no other ideas as to why adoption for Juce has been so slow...

Let me know if you want help doing that.  I have projects I want to do, but right now I would have to use wxWidgets and JUCE together, which is rather strange.  I have a lot of time on my hands right now, anyway...

Later, Jules!

BTW - there is a tiny mistake in the introjucer - first time running, it gives an error message stating 'NewProject' not found.  It's looking for the default project but it does not yet exist, as that is the first run..

Why I say we should move to wxWidgets is that it is a stable resource, we wouldn't have to do much with debugging it (hands off except for the inconsistencies between wxWidgets and JUCE), and it could save us the time of having to test every platform and such.  That said, the platforms that wxWidgets does not yet support can stay the way they are, but in the end it means much less work for you and whoever happens to be helping you.  The reason I would like to help now is that I have nothing 'better to do', and it runs hand-in-hand with what I want to do with JUCE anyway.  Let me know if you want me to dig into wxWidgets and make a Jules-enabled version of it to use within JUCE...

Regards, man....

There are two reasons why juce doesn't contain native widgets:

  1. I never had time to implement it
  2. There's never been a significant demand for it

Thanks for your offer of help, but I've really no idea what you have in mind when you talk about using wxWidgets. The only feasible way to add native widget support to juce would be to just write proper look-and-feels that use native UI objects, not to try to use any 3rd party code. It wouldn't be particularly difficult, just time-consuming. But the idea of some kind of frankenstein's-monster mash-up between my code and wxWidgets just sounds horrible!

Also: I think the demand for native widgets is both much lower than you think, and rapidly declining. With the rise of web-based UIs and mobile OSes, users just don't see native look-and-feels much these days: every device and website looks different, and customising your app/website is all part of the design process. The only platform where it would make sense would be OSX/iOS, but I can't really see much demand from people wanting their app to have a native Windows or Linux look!

wxWidgets - totally different ideas about how user interaction, component resizing and layouting works!
Bad mojo!

To me, Juce is useless without native controls, menus, windows, etc.  The drawing and other 2d/3d user interface controls are not the issue.

I would have to bow out of this one.  Maybe QT is a better fit for these projects, dunno.  But their pricing is an outrage - that's why I came back to JUCE.  Sorry, Jules - I have to disagree with you on this one...

You also have a security flaw in jucer.exe and introjucer.exe.  The vulnerability can cause the attacker to inject and execute arbitrary code on the target system.  For more information, see vulnerability report at http://www.checkpoint.com/defense/advisories/public/2012/cpai-16-aprk.html.

Sorry, Jules - completely uninstalling your stuff for now...  :*

Well, that's your prerogative. There's nothing to "disagree" with though - I simply said that very few juce users have ever requested native UI in juce. Sure, it'll be essential for some people, but clearly not most of my customers. I can't support everything that every programmer could possibly need, so I just focus on what the majority of people ask for, and obviously some people might not want the same thing.

Quite irritated that you're wasting my time with FUD about irrelevant security holes though. Your link describes a problem with UPX, not juce. Years ago I used to offer pre-built binaries, but haven't done so for a very long time. The "jucer.exe" that you're talking about no longer exists, and everyone compiles the introjucer themselves from source. UPX is not involved. Perhaps if you're running a massively out-of-date version that'd explain why your experience isn't so good.

Look, I like what you have done here and all, what I am saying is it just doesn't fit my requirements, which means I have to look for different alternatives.  Perhaps why nobody bothers to request it, as another user on here backed me with, is because they look at your library and then go somewhere else.  Of course your users would not request it, because they became a user only after looking through your features and giving it a try...

If you're going to get irrate at my 'FUD', I was using your 'latest and greatest', and still, the user interface looks tiny with text on linux, the user interface looks quite different and has a very different feel from what I would expect, meaning your library is more like Java and less like raw C++.  That said, I scanned your code with an antivirus scanner, which reported the vulnerability.  I realize it's a problem with UPX, however, the vulnerability still exists.  Goodbye, Jules. 

 

That said, I scanned your code with an antivirus scanner, which reported the vulnerability.  I realize it's a problem with UPX, however, the vulnerability still exists.

It does NOT still exist, because I've not even used UPX for years!

You've not actually said where you got this exe from, but it definitely wasn't from any repositories that I maintain or have control over.

Hey, I don’t see why you get so irritated - jules said nothing to offend you.
If Juce is not the right tool for the job, don’t use it for that.
There is no “one size fits all” - and as a developer it is your job to select the appropriate tool for the job.
And that’s the essence of what jules just said.

Actually, Jules may be right about the vulnerability.  This computer that I am using right now has been sitting away in storage for a while and may have had an old version [of JUCE] on it, and I just installed juce again to it - I'm not sure if I had an old version on here.  If I did, it was from when I was evaluating it from back in 2011...  which would explain the 'jucer.exe'.  If that's the case, at least clamAv didn't find any further vulnerabilities.

That said, I was only irritated at the 'FUD' comment.  That wasn't my intent.  I scanned with the only free scanner available on linux, clamav.  It doesn't generally report false positives.  That said, no, not all security scanners are accurate.  I believe it to be the job of the operating system to provide security; and on top of that most OS's don't give us enough access to truly protect against everything in a true AV manner (file scanning should be a secondary operation, not a primary one in preventing threats.)

To be fair and frank, everybody, including Jules; clamav also reported multiple vulnerabilities in netbeans for linux - and there were far more in it [Netbeans] than in JUCE (6 vs 2), and as Jules points out the 2 may be from a 2011 version.....

Thanks for the sanity check, lucem.  You are correct.  If it doesn't fit the project requirements, it just doesn't fit.  And that's fine.  QT is actually similar in a lot of ways to juce, only juce has an easier interface, and QT seems to be more difficult to understand how to deploy to other systems - they are really ambiguous about it.  But it fits my projects better, having closer to a native UI with the exception of linux menus, since linux uses a variety of windowing environments and QT makes you use, QT....  But it's as close to cross-platform native as I can get without wxWidgets, and I really, really don't want to use wxWidgets - it only provides the UI, but nothing else.  Which means with wxWidgets I would have the mundane task of merging it with something else - like Juce, or boost.  Boost may even be easier for that end, but either way it would be a nightmare...

Thanks guys.  I really wanted to use Juce for all of my stuff - but lucem is right.  I am evaluating multiple spots and want to use the same development platform for all my projects; and this just doesn't quite fit, sadly.  I will say that even though JUCE hadn't been reviewed by many people when you do a google search for 'c++ cross-platform library' or similar, I was glad to come across it.  It was really a close call, the only thing that made me shy away was the ui....   

Cooler heads prevail.  -V

Just wanted to say, I came here looking for native UI for Juce.  I will likely try to use wxWidgets with Juce, and see how that goes.  If I didn't want native controls, I'd probably write my GUI in HTML with Awesomium so I can get reusability across web and desktop environments.

Personally, I am very happy that Jules didn't add native control support. The strength of JUCE is the elegancy and consistency through-out the library. The way that you can customize the look and feel and the sensible approach to GUI programming are outstanding features and really make programming a joy. I fear that adding support for native controls would jepardize this considering that JUCE is a 'one man show'. In other words - thanks Jules and keep up your excellent work!

For better or worse, I am finding that a lot of sound engineers look down upon JUCE-based products because they don’t appear to be native apps. I wish this weren’t the case, as I like JUCE’s built in LookAndFeel(s).

The long-term solution to this problem – which would admittedly take a significant chunk of engineering effort to do – would be to write LookAndFeelWindows and LookAndFeelMac classes, and then specialize them for various versions of the target operating systems. I see no shortcut to going pixel by pixel and rewriting each LookAndFeel method to match its native counterpart exactly.

This approach would have the interesting side effect of being able to emulate Windows UIs on Mac and vice versa.

An example of this approach is BCGControlBar, which has laboriously reimplemented every Windows control in clean C++. https://www.bcgsoft.com/bcgcontrolbarpro.htm

Personally I think this is a flawed approach as you are then constantly playing catch-up with the OS UI changes.

Better (IMO) is to embed JUCE views within native windows, and make OS calls to instantiate native controls if thats whats needed. Like the approach of React Native.

2 Likes

A like alone is not enough for me to back up @adamski’s approach - I agree that recreating native widgets via LookAndFeel classes is NOT the way to go. Apple in particular likes to tweak the look and behavior of everything every year, and being even slightly off will instantly tip off users AND Apple (who very much dislike third party toolkits aping AppKit).

JUCE has ComponentPeer objects which allow for drawing native OS objects - if you want to try implementing it, that would be the way to go. I’ve looked into it, and it seems like it would be a monumental task to do for all platforms - especially with things like default widget sizes and layout options being different on each platform.

Beside that, I feel the pain of those who complain about the look of JUCE apps (especially on macOS). It looks fine for audio plugins where there’s usually some elaborate skin that isn’t meant to look native in any capacity, but for full fledged apps (cough Traktion) it sometimes looks a little (read: a lot) out of place.

A big source of this problem I think - and I really don’t mean to hurt anyone’s feelings here, I consider myself one of the most die hard fans of JUCE - is I think the default LookAndFeel classes look ugly as sin. The colors are totally weird (what app uses purple/grey?), the font size and typeface are off doing their own thing separate from the rest of the OS, and other obvious stuff that was fine in 2007 but feels incredibly janky now (non-native context menus, twitchy text in text editor, etc.). And that’s ignoring the under the hood issues that have cropped up such as the crazy CPU usage that has appeared in the software renderer with the introduction of HiDPI/retina screens, and the OpenGL renderer that’s meant to replace it has its own serious issues as well (anecdotal from what I’ve read and seen).

A place to look at how JUCE could look is Adobe’s apps - their UI toolkits have an amount of “native-ness” on par with JUCE (native macOS menubar, file dialogs), the difference being that the non-native widgets are beautiful (especially in Photoshop). I can only chalk this up to Adobe having an army of UI/UX designers and JUCE being designed by engineers(?).

I actually created an Adobe-cross-Apple-ProApps-like skin for Qt 4.8 at my last job, and have been working on creating another one on my own time as a JUCE LookAndFeel class - I’m just waiting on a feature to show up (or be acknowledged - Request: get system font (typeface name + size)). I’m planning on BSD licensing it and setting it free so people can start off with a nicer LookAndFeel that matches a more modern look (dark/light/skinnable/flat/etc.). So keep an eye out for that if that kind of solution works for you.

8 Likes

Intuitively, it might seem like an impossible approach to maintain, but that’s where a good class hierarchy shines. Practically speaking, both Microsoft and Apple haven’t truly rewritten their basic native controls in a long time. They have, however, spent a great deal of time tweaking fonts, layouts and spacing for each new release of their OS. They can’t simply throw away everything from release to release, as it would break all their pre-existing apps. As an approach, it looks much more hard than it actually is – you just have to spend a great deal of time looking at blown-up bitmaps and making sure that all your pixels match their pixels. It’s time consuming, but it’s not rocket science either. I’m not the only one who thinks this way: see https://github.com/jonathonracz/nt_lookandfeel for someone who’s done it for native fonts only.

One thing maybe not mentioned yet - which I think is significant - that in the particular market JUCE is aimed at - namely software and apps for music creation - it seems to me that virtually all apps I’ve come across that are popular - for the most part have entirely unique hand-crafted interfaces as their main screens. It may be the case that for some of the modal dialogs or “setting” type of windows or screens - certain developers have used native controls - for some aspects ( Korg Gadget comes to mind ) but for so much of the kinds of apps in question and particularly plugins- the UI is for the most part ENTIRELY non-native-looking. And often designed so specifically because musicians seek a sexy, attractive interface that doesn’t just look like another cobbled-together “IT” style business app.

Just my tuppeneth…

dunno

This is true, but the thing I miss is the iOS-like animations that are built into the native-GUI. Things like fade-in’s and other slight animations make the app feel more professional and unique. But we have done what Adam suggest: We get a graphics guy to go pixel by pixel and recreate the menus that we want. We just have a bunch of iOS-like graphics with transparencies that we use to mimic it.

@dstenning Thats very true, however there are cases when you do want native controls / transitions etc which is when its generally better to use the OS provided API’s.

@MIDIculous I suggest the opposite - using actual native widgets rather than recreate them.