I’ve found this to be working so far; i.e. locking the plugin, not locking the host, but not letting the dialog disappear below the host window as it has a somewhat ‘always on top’ behaviour. So basically pretty safe, and mirroring what’s happening on macOS, even if I disagree with not locking the host as state can be changed it feels like a win without too many workflow traps most of the time.
I’ve been doing some additional testing and have found juce::NativeMessageBox::showMessageBoxAsync to be similarly problematic as the original post for two reasons.
As these async message boxes are not modally associated with any window, they quite readily dive below the DAW window if not dismissed immediately in some DAWs. e.g. open a message box, click the plug-in window title / in plugin window / something in DAW instead of dismissing the dialog, and the message box is now right behind the DAW window; absolutely nothing was locked out so it’s very easy to click away from the message and then it gets buried. Pro Tools 2022.12 and Reaper exhibited this issue, Cubase was better behaved leaving the message box on top. (Quite surprising the behaviour was different).
Since we don’t have the more advanced technique of FileChooser which is able to close file chooser dialogs when the associated unique_ptr is nulled (handy if we are closing the GUI), it’s very easy to end up unloading a plugin that has a message box that has become lost (e.g. hidden below the DAW window if it wasn’t immediately dismissed) or even put to the side carelessly and not dismissed. Not only is that a bit messy being able to leave orphan message boxes all over the place if the user is not dismissing them, I’ve found in some cases it leads to a crash. Pro Tools and Reaper were quite happy with plugins being unloaded and the message box dismissing after unloading, but in Cubase if I unload a plugin before dismissing the message box I get a crash when the message box is closed. Presumably if callbacks were involved (in my test they were not) crashes would be much more common.
This discussion applies to Windows only, macOS the message box is locking out the DAW as desired so none of the nefarious deeds can be accomplished.
All of this was fine back using non-async / modal message boxes because they totally locked out the DAW and plugin (as happens on macOS with async which is what we want back on Windows too I’d guess). My attempts to be a good citizen and go all-in-async is not quite as smooth as hoped so far!
If the user can go back to the Daw with a file dialog open in the plugin, he can make changes to the plugin’s state, like mentioned above.
The UX/UI concept of an application-wide modal dialog should be applied here to prevent this. No backdoors should be allowed. The plugin is not the application, the host is the application.
Another risky area: suppose there are multiple instances of the same plugin, could the user open file dialogs in those instances? That could make a nice mess on the screen, I think. Which dialog is for which instance?
With modal dialogs, the user intuitively “feels” that if everything is blocked, he/she must make a choice: do the task for which the “dialog” window is displayed, or cancel the task by closing the dialog window.
Modal dialogs are meant to force users into such a funnel (if that is acceptable English): focus / attention is needed here! Either continue or cancel. But no steps aside, no side tasks.
My 2 cents, after 25+ years working as user interface designer. Now working as full-time (concerned ) plugin developer.
I really find these described new changes very counter-intuitive and would like to ask for at least the previous implementation to be restored for those who want to use the blocking approach. Maybe a switch, to allow the user to select his preferred blocking approach? This would compare to what is called application versus system modal.
Yes you can have multiple save-as dialog boxes open if they are different plugins, or the same plugin in two different formats open at the same time, but these dialogs are so obtrusive when they’re in an always-on-top mode that I doubt it’s going to be a trap of confusion that people fall into very often (it’s very easy to get out of just cancelling out of the dialogs).
If you need the old behaviour, just define JUCE_MODAL_LOOPS_PERMITTED=1 as mentioned in the breaking changes for Juce 6.1, but there are reasons we are being nudged away from using this. I’m generally down for that and can tolerate the new dialog behaviour even if I don’t love it, but with async message boxes which now increase the chances of a crash through any poor (but easy to do) user window management I am a bit concerned about using the default of async message boxes.
Thanks for the commit. I have done some rudimentary testing and not encountered crashes in Cubase, Reaper or Pro Tools when dismissing the box after deleting the plugin (or closing the UI) using the new facility. The box is dismissing when UIs are closed or plugins are unloaded. So on initial inspection this addresses the stability issue (my testing was quite brief though).
On Windows behaviour of the message box is still a little peculiar as we don’t always get any modal locking as seen on macOS, so I will likely continue to just allow modals on my Windows builds as those firmly lock the DAW and plugin UI out without any of the following strange behaviours:
Cubase (plugin always on top mode checked) - opening a popup temporarily hides the plugin window. Clicking back into Cubase reveals the plug-in again and it is above the message box. Clicking the message box hides the plugin. So there seems to be a little battle about who gets to go on top. It’s not a show-stopper but is a little odd.
Cubase (plugin always on top mode unchecked) - opening a popup it appears on top of everything, and behaves quite nicely.
Reaper & Pro Tools - popup appears above the DAW and plug-in as you would want, but if clicking the DAW or the plugin (contents or window title) the message box dives below the DAW and you need to move the plugin and/or DAW out of the way to read it again or dismiss manually (and get any callback invokes the user might need that are due to run after dismissal). A user could easily think they dismissed a box by clicking elsewhere when all they’ve done is buried it deep behind other windows, which has implications for what was supposed to happen in the callback (which now has been deferred until the user finds and dismisses the box so this action may be delayed or no longer be appropriate, or may never run at all if the UI/plugin is closed before they find it).
So some behaviours are a bit of an inconvenience and might cause unexpected behaviour, but are not necessarily dangerous as we don’t crash when plugin UIs are closed/unloaded anymore. I’m not sure if these window ordering issues can be improved or not.
) plugin developer.