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.
The previous implementation would pass the mouse wheel event up to the
component's parent, as long as the parent was enabled. This meant that a
wheel event on the innermost component of a hierarchy such as
"[[disabled] enabled]" would send the event to the parent, but a wheel
event on the innermost component of a hierarchy such as
"[[[disabled] disabled] enabled]" would 'eat' the event and prevent it
from propagating.
After this change, unhandled mouse wheel events will always be passed to
the nearest enabled parent. This behaviour is more consistent and
intuitive.
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.
This change allows mouse events (including enter and exit events) to
reach unfocused views on macOS. This matches the behaviour of unfocused
windows on Linux and Windows, where components paint in their "hovered"
states even when the application window is in the background.
As a byproduct of using tracking areas on macOS, we can remove the fake
mouse move generator.
This commit removes the various compiler-specific JUCE_DEPRECATED macros and replaces them with C++14's deprecated attribute. It also removes the JUCE_CATCH_DEPRECATED_CODE_MISUSE flag as we can rely on the override specifier catching usage of these old virtual methods, and tidies up the DOXYGEN preprocessor checks as they were inconsistent across the codebase.
- Add AlertWindow::show() and showAsync() methods that take a MessageBoxOptions argument
- Add NativeMessageBox::show() and showAsync() methods that take a MessageBoxOptions argument
- Update the DialogsDemo to demonstrate the new methods
- Deprecate AlertWindow::showNativeDialogBox() in favour of the NativeMessageBox methods
- Pass button strings specified in MesssageBoxOptions to native dialog boxes correctly
- Use modern TaskDialog on Windows for the native dialog box where available
When rendering with OpenGL, the paint function is called from a
background thread. If we call `isMouseOver` from the paint function, we
may end up calling native functions via the ComponentPeer, which causes
threading warnings on macOS.
Previously, getScreenPosition would return a result in the component's
coordinate space if it was called on a component that was not directly
or indirectly on the desktop. This behaviour is surprising and difficult
to program around. This change should ensure that the result is always
in the screen's coordinate space.
