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.
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 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"
Showing the tip will in turn call getDesktopScaleFactor(), accessing the
lastComponentUnderMouse. In some cases, it was possible for
lastComponentUnderMouse to point to a deleted component, resulting in
UB.
There are two changes in this PR:
- Using a SafePointer rather than a raw pointer ensures that calls to
getDesktopScaleFactor() will always be safe, regardless of when they
happen.
- Moving the assignment of lastComponentUnderMouse to before the call to
displayTipInternal() ensures that the returned scale factor is that of
the component that the mouse is currently hovering.
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.
Previously, the following series of steps would leave the window at
full-size on Windows:
- Open a JUCE Window
- Maximise it
- Minimise it
- Click the maximise button
The expected behaviour is that the window should return to its initial
size and position, but instead the window still fills the screen.
This issue wasn't present on Ubuntu/Unity because minimising does not
invoke ComponentPeer::handleMovedOrResized on that platform. It was not
present on macOS because the system is responsible for restoring the
previous window size on that platform.
- 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 bridging 32-bit/64-bit plugins on Windows, the plugin is hosted in
an auxilliary process, and the plugin's editor is embedded into an HWND
owned by a different process (the plugin host).
Previously, the `isForegroundProcess` check would fail for bridged
plugins, because the foreground window may belong to the DAW, rather
than to the auxilliary hosting process.
This patch adds an additional check, to find whether the same process
owns both the foreground window, and the window which embeds the
PopupMenu's target component. In this case, we avoid immediately
dismissing the PopupMenu.
For DialogWindow, uses the scale of componentToCentreAround.
This allows drawing dialog windows at the expected scale in plugins.
An associated component must be supplied in order for this to work.
attila
reuk
Tom Poole
ed