Unfortunately I don’t think any of the suggestions would resolve the problem.
This won’t allow popup windows to have completely transparent rounded corners.
This initially seemed like a viable solution, but it seems that any part of the child window that is not on top of the parent window is still painted with a magenta background. To test, I applied this patch:
Then, I built the DSPModulePluginDemo AU and loaded it in Logic on an M1 mac. Popup menus which are not entirely contained by the editor window sill have partially magenta backgrounds.
This is not a general solution, it only fixes the case where the desired corner radius matches that set by the OS. It doesn’t fix the issue for windows with a translucent background.
This would force the menu to use OS styling, which may not be acceptable to some developers. It would also only provide a solution for PopupMenus. This solution would not work for arbitrary floating widgets such as dragged items, tooltips and so on.
All this is to say that I still think the solution that will yield the most consistent results across platforms is to avoid opening new top-level windows entirely, and to draw widgets such as menus, tooltips, and dialogs directly into the editor window wherever possible.
I casually noticed that this workaround is not working any longer. Despite I have my LaF class taking the topLevelComponent, the behavior on Logic is not the same as before: magenta overlay on transparencies and menus going out the plugin boundaries.
EDIT: I tested a plugin built with 6.0.8 and it works as expected on Logic Pro X. New plugins and updates I’m building with 6.1.5 (so no changes made on the LaF), are showing the issue. I need to figure out what changed in between and why Component* getParentComponentForMenuOptions (const PopupMenu::Options&) override won’t get called.
@reuk I can confirm that the problem is because of plugins running in their own process. I could trigger the same pink issue with an Intel plugin running in Silicon Reaper. This so called security measure of apple is stupid to say the least
The magenta backgrounds are present on all secondary windows in out-of-process-hosted AUv3 plugins. If you’re testing in AUv3, then the answer is probably yes, but there’s not enough detail in the question to know for sure. I haven’t seen the exact issue you’re talking about. Do you see the problem in all formats, or in specific ones? On which platforms, and in which hosts?
I’ve tried this trick but the results are only partially ok. First of all, I’m on iPadOS (Standalone and AUv3), and I’ve got a couple of comboboxes inside some components that are AudioProcessorEditor’s children.
I pass my AudioProcessorEditor to the LnF class using getParentComponent() and everything works as expected: the popup related to the combobox is shown correctly and it is actually able to expand over the boundaries of its parent component (and that’s right since I’ve passed the whole ProcessorEditor and not a “this” reference).
If I do the same thing, nothing happens: the combobox popupmenu does not show up. If I pass “this” the popupmenu shows up, but it is restricted inside the parent component, and therefore is both ugly and difficult to use (it cannot go over the boundaries of “customComponent1” and so on for the others).
Is there something that I’m doing in the wrong way? This problem happens only on iPadOS in AUv3, on desktop everything is good