When bridging 32-bit/64-bit plugins on Windows, the plugin is hosted in
an auxilliary process, and the plugin's editor is embedded into an HWND
owned by a different process (the plugin host).
Previously, the `isForegroundProcess` check would fail for bridged
plugins, because the foreground window may belong to the DAW, rather
than to the auxilliary hosting process.
This patch adds an additional check, to find whether the same process
owns both the foreground window, and the window which embeds the
PopupMenu's target component. In this case, we avoid immediately
dismissing the PopupMenu.
This change ensures that popup menus will be dismissed when hosted
plugin windows are moved, even when these plugin views are themselves
hosted inside JUCE views, like those used in the AudioPluginHost.
When drawing a popup menu for a target component with a non-unity scale,
the contents of the component were being drawn with an unwanted vertical
offset.
This fixes a regression introduced by
6e9261ea66 which meant that components
were not given a chance to respond to shortcut keypresses if those same
keypresses were registered for a menu item. This resulted in behaviour
where shortcuts such as 'cmd+c' would not be passed to a focused
TextEditor if a different command with the same shortcut was registered
in the main menu.
With this change in place, we now check whether the menu item's shortcut
keys match the current event's pressed keys. If the keypresses match, we
can assume that the event was triggered by the keyboard, and dispatch
the keypresses to the ComponentPeer. If the keypresses do not match,
then the menu item was likely selected using space/return, or by
clicking, in which case the event is dispatched directly to the
ApplicationCommandManager.
This resolves a regression which was introduced in
74ca3b44c4.
Prior to that commit, drag and drop on Linux/X11 worked as expected.
DragAndDropContainer::performExternalDragDropOfFiles allowed dropping
files onto other applications.
After the faulty commit, this function may cause the window manager to
enter a bad state in which the drag operation never finishes, making it
impossible to switch between windows or close windows.
I think the issue happens because the DnD source may receive (spurious?)
XdndLeave messages during the drag, which cause the peer's entry in the
dragAndDropStateMap to be removed. Before the faulty commit, each peer
had its own drag and drop state object, which was not destroyed in this
way.
This change will keep the peer's drag state object alive, even when an
XdndLeave message is received. The entry will still be removed when the
peer's window is destroyed.
IFileDialog::Show and CoUninitialize both seem to require the main
message loop to be active and running when they are called. If we block
the message thread while calling these functions, we may cause a
deadlock.
The destructor of the Win32NativeFileChooser was blocking the message
thread until the background thread exited, but the background thread was
unable to make progress while the message thread was blocked.
To work around this issue, we now pump the message thread in the
destructor of the Win32NativeFileChooser. If a dialog is currently
active, this should allow it to exit gracefully.
Note that we cannot use MessageManager::runDispatchLoopUntil here:
- MessageManager::runDispatchLoopUntil will not process any messages if
the quit message has been received, which could lead to deadlocks if the
FileChooser is destroyed after the quit message has been posted.
- This function isn't defined when JUCE_MODAL_LOOPS_PERMITTED is disabled.
This resolves an issue on macOS Catalina when using
JUCE_COREGRAPHICS_DRAW_ASYNC where windows would sometimes fail to
completely repaint when they were unminimized.
Ardour seems to listen to the bounds of the plugin window, and will call
`onSize` on the plugin editor when move/resize events are sent to the X
window - even if the size of the window didn't really change. This can
result in an infinite resize loop, where calling `onSize` on the VST3
instance sends a resize event to the plugin window, and this event
causes Ardour to call `onSize` on the plugin view.
To get around this, the Linux ComponentPeer will no longer request a
bounds change from the window system if the requested bounds are the
same as the current bounds.
Previously, things like PopupMenus which were created in their own
windows were not being scaled correctly on HiDPI displays on Linux.
This patch forces the display scale to 1.0 in plugins, meaning that
the transform applied to the main plugin window is the sole source
of truth for component scaling in plugins.
It seems like shared_from_this may not be enabled when a unique_ptr is
assigned to a shared_ptr (although it *should* be enabled when
constructing a new shared_ptr from a unique_ptr). Functions that return
objects that may need to use shared_from_this now return shared_ptr,
just to be safe.
Additionally, in some cases, shared_from_this was being called from
Thread::run after the last reference to the shared object had been
released. We now call shared_from_this during 'open', which will always
run on the message thread while at least once reference to the shared
object is alive.
reuk
ed
Tom Poole