Applies the previously missed line spacing value of the TextEditor.
The changes in JustifiedText fix calculating the vertical position of
the first line for the case where ShapedTextOptions has the following
settings:
isBaselineAtZero() == false,
getHeight().has_value() == false
getLeading() > 1.0f
This case however is only triggered by the TextEditor, as with all
functions in GlyphArrangement at least one setting is different.
The type std::pair<Point<float>, float> inherits from an empty base on
C++17. Due to a bug in GCC 10.1 this would prevent the compiler from
treating it as a HFA type, and it would use a different register to pass
it, than it does in newer GCC versions. Because of this ABI change an
ABI warning is emitted by GCC today, hinting at this fact.
By using a custom struct that does not inherit from an empty base we are
avoiding emitting this warning.
We now require a mouse movement before highlighting menu items. This is
intended to ensure that the user has intentionally highlighted the menu
item that they wish to trigger.
This makes behaviour more consistent between the parented and
non-parented display modes.
Before this change, parented popup menus wouldn't respond to mouse
clicks until the mouse was released once, which meant that clicking and
dragging the mouse over a menu wouldn't trigger a menu item on mouse-up.
Before this change, when starting a mouse drag from a nested view such
as a webview, JUCE was unable to automatically determine which component
is associated with the drag.
Instead of relying on automatic detection, users can pass the
"sourceComponent" argument when initiating a drag to specify the parent
view that should receive associated drag events. However, previously the
sourceComponent was only used to find the view associated with the
mouse-down, but not the mouse-up. Automatic detection was always used
for the mouse-up, but this could fail in the case of a drag started from
a nested view.
Now, the drag event source will store a weak reference to the source
component provided by the user, and use the same component for both
mouse-down and mouse-up events.
Previously, the vblank's thread loop would block on each iteration until
the current async callback had finished, at which point a new async
callback would be immediately triggered.
The new implementation only waits on the vblank event. If a vblank
callback is still in progress the next time the vblank event is
signalled, we assume the last frame is overrunning and avoid sending a
new async update.
The intention of this change is to avoid saturating the message thread
with expensive vblank callbacks. It's also nice to remove a lock,
although that's just an incidental change.
