Native alerts?

General JUCE discussion
1

Hello Jules,

so far I have used JUCE to write applications for the Windows platform. Now I would like to port those apps to the Mac OS and distribute them through the Mac App Store. Later still I would like to try to port them even to iOS.

I have already built the Mac versions, just encountering some difficulties due to the non-standard version of STL used by Visual C++ and my ignorance of Xcode. But when I saw my applications appear on the iMac screen, I appreciated once again the capabilities of JUCE!

Having been a Mac programmer in the distant past, I know Apple’s attention to the look and feel of applications. I then read the Human Interface Guidelines, the Mac App Store Review Guidelines and downloaded some music application from the store to see if an application made with JUCE would be accepted.

I was reassured to see at the top of the charts two cross-platform applications, VirtualDJ and Mixx, both using for the main window a completely custom user interface, equivalent to an application made with Juce.

However, both use the native Aqua interface for standard dialogs and alerts. And actually I had the impression that the JUCE Alerts are a bit out of tune on Leopard. That is why I propose the following change.

Limited to the static methods showMessageBox(), showOkCancelBox() and showYesNoCancelBox() of the AlertWindow class, I think you could implement a transparent manner to choose whether to use a LookAndFeel -based version or a native version.

More or less, it should consist in:

adding a AlertWindow::useNativeBoxes()

adding a ‘useNativeBoxes’ parameter to AlertWindowInfo::AlertWindowInfo()

modifying AlertWindowInfo::invoke():

if (useNativeBoxes) { return AlertWindow::showExtendedNativeDialogBox (title, message, button1, button2, button3, iconType, numButtons); } else { MessageManager:: getInstance () -> callFunctionOnMessageThread (showCallback, (void *) this); return returnValue; }
and finally implementing AlertWindow::showExtendedNativeDialogBox() for the various platforms, which should not be too difficult.

Clearly, I could try to do it myself, but I know from experience that making unilateral changes to Juce is a problem whenever the library is updated. That said, I am of course open to collaboration.

What do you think?

2

It sounds like you are volunteering to write it!

I approve!

3

As I said, I would gladly, but only after receiving the blessing of Jules.

4

Well, there’s already a showNativeDialogBox method, and I’ve often thought about adding a couple of others to provide yes/no/cancel options, but have never got around to it. If you fancy kick-starting me by having a go, I’d certainly take a look at what you end up with!

[quote]More or less, it should consist in:

adding a AlertWindow::useNativeBoxes()

adding a ‘useNativeBoxes’ parameter to AlertWindowInfo::AlertWindowInfo()

modifying AlertWindowInfo::invoke():[/quote]

none of that sounds right to me, and it’d be difficult/impossible to make any AlertWindow native, because they can contain arbitrary custom juce components. If you’re suggesting that AlertWindow::useNativeBoxes() should be some kind of static global setting, then that’s certainly the wrong place to put it - any kind of global setting would belong in the lookandfeel class.

5

Yes, I thought just to extend or add a method similar to showNativeDialogBox(), to handle the same parameters used by the static methods of AlertWindow (number and title of the buttons, type of icon). In fact I just did an experiment using that method.

Yes, I thought of a global static flag in the AlertWindow class, but as you rightly said, it should be put in LookAndFeel.

I know that AlertWindow has capabilities that go beyond those of a standard alert on all platforms and in fact I would like to limit myself to deal with cases covered by the static methods of AlertWindow. For example, I would like that the call to showYesNoCancelBox() made ​​by FileBasedDocument::saveIfNeededAndUserAgrees() showed a native alert.

6

Yes, I guess that if it was limited to those static methods then it’d probably be quite easy to do.

7

Thank you very much, Jules!

8

No problem. I’ll probably add some more types as well, in future - a native progress box would be handy.