- Improve default performance when components check if they are opaque
- Allows all components to take advantage of setPaintingIsUnclipped
- Give more control to opt out of opaque checks separate from setPaintingIsUnclipped
With this change disabled components become discoverable by screen
readers, similarly to how OS native user interface components behave by
default.
The KeyboardFocusTraverser will still skip disabled components so this
does not affect keyboard navigation without screen readers.
In the DemoRunner, switching to and fro between the Settings tab and
the Demo tab displaying the OpenGL demo could lead to
GL_INVALID_OPERATION errors. This is because closing the demo shuts
down the GL context, destroying resources such as framebuffers. If any
Image objects backed by framebuffers outlive the context, they will be
invalidated. Component effect images are especially likely to hold onto
invalid framebuffer references.
With this change in place, images cached by Components will be
invalidated when the attached GL context goes out of scope, and will be
recreated when the new context is created.
This reverts 515e9b9f89.
In order to avoid recursive calls through WM_NCHITTEST, we remove calls
to Component::contains in DocumentWindow::findControlAtPoint.
This partially reverts commit 555b667d22.
Using ComponentPeer::isShowing instead of ComponentPeer::isMinimised
inside Component::isShowing can cause problems when displaying OpenGL
components.
Specifically, OpenGL components use a ComponentMovementWatcher to
determine when they should be attached/detached from the parent window.
The ComponentMovementWatcher updates whenever a component visibility
change event is emitted, which happens in two cases:
- Component::setVisible is called on the OpenGL component or an ancestor
- ComponentPeer::handleMovedOrResized is called in response to a
minimisation state change
When handling either of these events, the ComponentMovementWatcher will
call Component::isShowing to determine whether or not the component is
really showing.
The problem is that the result of ComponentPeer::isShowing may change
independently of changes to the Component visiblity state or
ComponentPeer minimisation state, so the ComponentPeerWatcher might not
notify its listeners when a component is really shown/hidden.
One potential workaround would be for the ComponentPeer to send
notifications when the showing state of the window changes, so that the
ComponentMovementWatcher can forward those notifications. The main
problem with this approach is that on Windows, the window doesn't seem
to receive a message on hide/show, and it's not clear whether there
exists some other approach to detect a hide/show event.
If there were some event we could listen for on Windows, then we could
call Component::sendVisibilityChangeMessage in response to this event
and things would *likely* work at that point, but this may still have
unintended side-effect. As a result, I think the best approach to
restore the old behaviour is to revert the change to
Component::isShowing. The implementations of ComponentPeer::isShowing
have been left in place so that users can do still query the real
visibility state of native windows if necessary.
This change makes it slightly easier to audit invariants of
ModalComponentManager, as we can now be certain that only member
functions of ModalComponentManager can access its data members.
- Created a new detail namespace
- Moved shared module implementation details into the detail namespace
- Split dependencies so source files only rely on details in the detail namespace
- Removed all code from the juce_gui_basics.cpp file
