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.
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, 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.
This restores the functionality of JUCE_COREGRAPHICS_RENDER_WITH_MULTIPLE_PAINT_CALLS.
Using this preprocessor flag may avoid Core Graphics rendering much larger regions than
necessary, but the small regions that are rendered will likely be rendered slower.
Whether using this flag improves or degrades the performance of your rendering overall
will be specific to each application.
Previously enabling JUCE_COREGRAPHICS_RENDER_WITH_MULTIPLE_PAINT_CALLS was ineffective
from versions of macOS around 10.13, but enabling it didn't have any negative impact on
performance. Now enabling JUCE_COREGRAPHICS_RENDER_WITH_MULTIPLE_PAINT_CALLS may result
in slower rendering.
This restores the functionality of JUCE_COREGRAPHICS_RENDER_WITH_MULTIPLE_PAINT_CALLS.
Using this preprocessor flag may avoid Core Graphics rendering much larger regions than
necessary, but the small regions that are rendered will likely be rendered slower.
Whether using this flag improves or degrades the performance of your rendering overall
will be specific to each application.
Previously enabling JUCE_COREGRAPHICS_RENDER_WITH_MULTIPLE_PAINT_CALLS was ineffective
from versions of macOS around 10.13, but enabling it didn't have any negative impact on
performance. Now enabling JUCE_COREGRAPHICS_RENDER_WITH_MULTIPLE_PAINT_CALLS may result
in slower rendering.
The helper function setComponentAsyncLayerBackedViewDisabled has been replaced
by a windowRequiresSynchronousCoreGraphicsRendering ComponentPeer style flag.
This partially reverts f43784dc: "macOS: Propagate focus loss message when resigning key window status and only grab focus if window can become the key window"
The change introduced in 92f350e617 led to
a regression in the MoveEndpointByUnit function. In this case, a
backward movement by a single character *should* move the endpoint as
long as it remains within the text range.
The issue addressed by the faulty commit is better fixed by
special-casing the 'character' unit case in the ExpandToEnclosingUnit
function.
eabcfbad26 incorrectly set the collection
behaviour NSWindowCollectionBehaviorFullScreenPrimary on all top-level
components, which would cause popup menus and callouts to appear in
their own space when launched from an app running in full-screen mode.
In CoreGraphicsPixelData::createImage, image data was copied from a
BitmapData created from the Image passed into the function.
The BitmapData instance didn't keep track of the size of the buffer it
pointed to, so the buffer size was computed by multiplying the
BitmapData height by its line stride. However, if the BitmapData pointed
to a subsection of an image, the `data` pointer might be offset from
the allocated region, and `data + lineStride * height` would point past
the end of the allocated region. Trying to read/copy this range would
cause a heap buffer overflow at the end of the range.
This change adjusts BitmapData so that it keeps track of the size of the
allocated region. Taking a subsection of an image should subtract the
data pointer offset from the size of the allocated region.
Narrator on Windows seems to call ExpandToEnclosingUnit to find the
character immediately following the current cursor position. When
expanding a degenerate range with position `input` (used to represent
the cursor position) to a single-character range, the returned range
should start at `input` and end at `input+1`. Previously,
findTextBoundary() would always return the position before
currentPosition when searching backwards by character, so the result of
ExpandToEnclosingUnit would be off-by-one when expanding to the closest
character.
The bug was triggered on Monterey where a pressure of 1 is reported
while a mouse button is being held down. This caused an extra drag
event being triggered between mouse down and up events, even if no
movement occurred.
