Beware that this may look like this other issue I was having, but it’s not the same thing: closing these windows doesn’t trigger the beep, so that other issue is still solved in 6.1.1, no regression AFAIK
This change will make plugin views (and other heavyweight views) listen
to their containing window, and dismiss any blocking modal components,
such as PopupMenus when the window is moved or resized.
There appears to be a bug in the implementation because when I’m opening a new modal window, I’m not moving nor resizing any of the existing ones.
Aside from that, I can see the rationale for dismissing temporary modal components when a plug-in view is acted upon, for example by the DAW.
On the other hand, doing that for every Component that has an heavyweight view (i.e. I suppose that includes those with a native title bar. What about those added to the Desktop?) seems overkill, and bordering into “breaking change” territory. Or am I missing something?
I confirm that these are the offending commits.
And for me it happens precisely in a case where I open a plugin window from a modal dialog (I’m writing a host). In my code, I open the plugin editor from the modal window and then close this modal window.
If I comment out the content of void dismissModals(), no more alert sounds.
Edit: I simply changed my logic to dismiss the main modal window before instantiating the plugin editor, but I guess this is still a bug to some extent?
I think that the intended behaviour is useful. If you have an app window with a native titlebar, and that contains some popup menus, it’s expected that moving the app window, or creating new heavyweight windows will dismiss the menus.
At the same time, you’re right that the peer is currently a little too enthusiastic about trying to dismiss modal windows - if the modal window is itself a long-lived dialog, creating other windows probably shouldn’t attempt to dismiss it. It sounds like the peer should only try to dismiss the modal component if the modal component’s peer is marked with the “windowIsTemporary” flag. This way, popup menus and other transient windows will still be dismissed by creating a heavyweight window, but long-lived windows will not.
Am i the only one, but with latest develop i get an alert sound each time i open/create a window now?
Not the case with master branch.
And i don’t know if it is related but the “Preferences” sub-menu in Apple’s menu is also broken.
Anyway i’ll investigate later and will open another thread with more details.
I’m not seeing either of these issues in the AudioPluginHost or Projucer. If you are still seeing this issue, please provide some sample code to reproduce the problem, and let us know the platform you’re using.
@reuk FYI I got another report today that the ding occurs on Windows. Out of curiosity why do you say that Windows does not have this issue, although this commit was pushed?
I can try a minimal repro if needed, but it’s basically happening when opening a plugin window from a modal dialog.
I tested a few different JUCE apps (DemoRunner, AudioPluginHost, and the minimal repro from the initial post in this topic) and didn’t observe any unexpected calls to LookAndFeel::playAlertSound().
The handling of events/input is quite different between the different ComponentPeer implementations so it’s conceivable that an issue like this does not affect all platforms. However, it’s also possible that I overlooked something while testing. If you’ve observed behaviour that seems buggy, please provide some minimal code so that we can reproduce the issue here.
It appears that i have a sound alert for each entry in the menu bar on macOS 11.6 ; Each time i select an item : bip. Nothing related to window creation. I’ll try to make a minimum exemple and/or find where it started to happen in commits history.