The TextHolderComponent and Viewport::componentHolder don't have any
accessible semantics, so they shouldn't be included in the accessible
component hierarchy.
Previously, when navigating in a text editor by words, the cursor would
get 'stuck' after moving a single word. This issue should now be
resolved.
Additionally, the cursor position was not updated properly when
adjusting a selection, and would instead be moved to the end of the
selected range. With this patch applied, the cursor should now be set to
the correct position when modifying selections. When extending a
selection backwards, the cursor will display at the beginning of the
selected range, rather than the end.
Finally, most Android apps announce the 'skipped' characters or words
whenever the cursor is moved, but this feature was broken in JUCE. This
patch enables this feature.
This change fixes an issue where the touch keyboard failed to show when
selecting a TextEditor.
On the current versions of Windows 10 and 11, the undocumented
ITipInvocation workaround no longer seems to be required, so it has been
removed.
The isTabletModeActivatedForWindow function is no longer needed, and has
been removed. This function also appears to return inconsistent results:
the window may be in 'desktop mode', but devices with touchscreens
should still display the keyboard when selecting a TextEditor by touch.
Previously, individual components had to ask the peer to hide and show
the keyboard, by calling textInputRequired() and
dismissPendingTextInput() respectively. When an onscreen keyboard (OSK)
was required, most Peer implementation would directly hide/show the OSK
inside these function. However, the iOS ComponentPeer implementation
instead listened to the application's global keyboard focus, and only
opened the OSK when the focused component was also a TextInputTarget
with active input.
The iOS scheme seems like a better design, as it enforces that the OSK
hiding and showing is synced with the keyboard focus of the application.
In the other implementations, it was possible for a Component to call
textInputRequired even when it didn't have the keyboard focus, putting
the application into an inconsistent state. The iOS scheme also makes
the TextInputTarget interface more useful, as it enforces that the OSK
will only display for components that implement TextInputTarget, and
return true from isTextInputActive().
This patch changes all Peer implementations to match the iOS
implementation, improving consistency. Each time the global keyboard
focus changes, refreshTextInputTarget is called automatically, and the
OSK is shown if the focused component is a TextInputTarget that returns
true from isTextInputActive, and hidden otherwise. Components can also
call refreshTextInputTarget manually. This should be done whenever the
component updates the return value of isTextInputActive(). Effectively,
the Peer is now responsible for keeping track of the focused
TextInputTarget, rather than allowing individual components to hide and
show the OSK at will.
Additionally, this patch adds an option to the TextEditor to
automatically dismiss the OSK when the mouse is clicked outside of the
editor. This should improve user experience on mobile platforms, where
touches on sibling components may cause a TextEditor to gain keyboard
focus and unnecessarily display the OSK.
Until now when a Component without a parent was passed to setOwner() the
ParentVisibilityChangedListener would not install any hooks to any
components, hence it would not be notified, when the owner was added
to a parent.
Some AUv3 presets crash when querying the set of presets in Loopy Pro.
The issue seems to be because `addPresets` may end up being called
concurrently with the host's queries.
The following was observed for a VST3 plugin hosted in Live 11.1 with
auto-scaling disabled:
- It never calls setContentScaleFactor on the plugin's UI, so the
wrapper has to check the current display on a timer and update the
current scale factor when necessary.
- It calls canResize on the plugin view after opening it, but doesn't
seem to respect the result of this call. According to the VST3
documentation, a host is supposed to only call checkSizeConstraint
during a live resize operation (which should only happen if the plugin
reports it can resize), but Live calls this function every time the
user drags the editor. It also passes the result of this function to
onSize, whether or not checkSizeConstraints reported success.
- When dragging an editor between displays, Live will continue to call
checkSizeConstraint and onSize with the editor’s old size in physical
pixels. In some cases, JUCE's "scale factor check" timer callback
fires, resizes the view to the correct size, and then Live
asynchronously calls onSize again with the editor's old size in
physical pixels, resulting in the editor being set to the wrong
logical size.
This patch ensures that checkSizeConstraint always returns the current
size of a nonResizable editor. This means that the logical size of the
editor should not change when the result of checkSizeContraint is used
to resize the window.
