Previously, a touch on a component outside the Viewport would interrupt
and cancel a scroll gesture inside the Viewport.
Now, the Viewport will respond to all drag events from the input source
that started the drag, allowing the Viewport to be scrolled with one
input source while adjusting other controls with another input source.
The FontsDemo is useful for testing this behaviour, as it has two
Viewports on a single screen, along with some other controls.
5f7ad995af introduced an issue where the
string of external libraries would be escaped in one go. This is
incorrect, because only the individual paths should be escaped. The
semicolons separating each path should not be escaped.
File::getContainerForSecurityApplicationGroupIdentifier will return the
path to a container which is shared between all apps using the specified
app group ID. This might be useful if you need to share resources
between a standalone app and an AUv3 plugin, for example.
The previous implementation would fail to open directories with names
that contained spaces, as the space would be escaped and then quoted.
I don't think it's particularly meaningful to supply parameters when
opening a file in this way (especially not quoting the parameters too!)
so I've removed that functionality.
Previously, it wasn't safe to access Font instances from multiple
threads because there was a chance that they might reference the same
shared internal state. In this case, calling getTypeface() or getAscent from
two threads simultaneously would cause a race on the typeface and ascent
data members, even though the Font instances appeared to be disjoint.
With this change in place, it is now safe to use Font instances from
multiple threads simultaneously.
It is still an error to modify the same Font instance from multiple
threads without synchronization!
// Fine:
Font a;
Font b = a;
auto futureA = std::async (std::launch::async, [&a] { /* do something with a */ });
auto futureB = std::async (std::launch::async, [&b] { /* do something with b */ });
// Bad idea:
Font f;
auto futureA = std::async (std::launch::async, [&f] { /* do something with f */ });
auto futureB = std::async (std::launch::async, [&f] { /* do something with f */ });
Previously, the samplerate combo would display as a blank box in the
case that the device's actual samplerate wasn't one of the "available"
samplerates reported by the device.
By defining JUCE_IOS_AUDIO_EXPLICIT_SAMPLERATES, the iOS audio device
will always use the requested samplerates instead of querying the
current audio device for the samplerates it supports. This is useful
because certain hardware (such as the Focusrite iTrack Dock) takes a
long time to set new samplerates, which can end up freezing the main
thread for significant lengths of time.
This approach is inspired by the AUM app for iOS, which appears to
provide a fixed list of "allowed" samplerates, rather than querying the
device for its allowed samplerates.
Merging a plist which contained UIBackgroundModes or
UISupportedInterfaceOrientations keys could result in these keys being
duplicated in the generated plist.
This patch will avoid adding a new array if the array's key already
exists in the plist.
