On Windows, when opening a plugin editor, destroying the plugin
instance, and then creating a new instance and opening its editor, the
plugin would crash because the VBlankDispatcher singleton could not be
recreated.
Previously opening a PopupMenu and then clicking somewhere outside
the application would cause the mouse button representation to be
stuck in a down state.
In 6f3fb5a29f windowBorder member of
LinuxComponentPeer was changed to mean the logical size of the border
that is independent of the current scale factor. This was done to fix a
bug and make it consistent with the bounds member, which is also
independent from the scale factor.
This change wasn't taken into account in XWindowSystem::setBounds()
causing a positioning bug.
An animated drag operation will now stop if the user interacts with
the content area again before the animation is finished. It is also
stopped if the user interacts with the scrollbars.
Previously, positioning such an item would hang while trying to find an
appropriate position for the item, because no position in the grid was
suitable, and implicit cells in the layout direction would be added
until a viable position was found.
We now ensure that there are enough cells in the cross direction to hold
each of the auto-placement items before trying to position those items.
On Windows, when opening a plugin editor, destroying the plugin
instance, and then creating a new instance and opening its editor, the
plugin would crash because the VBlankDispatcher singleton could not be
recreated.
The X42 stepseq.lv2 has an input atom port without the "control"
designation, but that still supports time:Position events. In order to
support this plugin, JUCE hosts will now send position info to any input
atom port that is marked as supporting this event type.
The host sync feature in stepseq.lv2 also requires the bar count to be
included in the position information.
Observed on Ubuntu Linux. Occasionally, the loop checking the
condition_variable in the plugin scanner would spin indefinitely.
The cause appears to be that handleMessageFromWorker could be
called immediately after sendMessageToWorker, but before locking the
mutex. If this happens, gotResponse will be false during every call to
condvar.wait_for, and the loop will never exit.
The rewritten version of the scanner always resets gotResult immediately
after the condvar is woken successfully, so a call to
handleMessageFromWorker or handleConnectionLost will always cause a
subsequent call to condvar.wait_for to exit successfully.
The Superprocess class has also been refactored and extracted to avoid
a circular dependency between Superprocess and CustomPluginScanner.
