Hello Christopher
Anthony,
I think I disagree with Applet returning true to isValidateRoot. If I
am not mistaken, I think I saw some people placing an applet in their
component hierarchy as if it was a normal component. Invalidation
should propagate so that outer components can revalidate and thus have
proper layout calculations. Thus I think the only AWT components that
should return true are the ones with an outer parent (window class
hierarchy).
It is actually not recommended to tread Applet as a normal component
The javadoc says:
* An applet is a small program that is intended not to be run on
* its own, but rather to be embedded inside another application.
I would expect some strange bugs in an application that uses JApplet
or Applet instead of general containers like JPanel
Swing code treats Applet like a topLevel component
which reflects in different places
see
SwingUtilities.convertPointToScreen():
SwingUtilities.getRoot(Component)
KeyboardManager.getTopAncestor()
PopupFactory.ContainerPopup.fitsOnScreen()
and so on...
RepaintManager.addInvalidComponent() also uses the same logic for
Windows and Applets, please have a look at the method's implementation
By the way, when isValidateRoot() method will be brought up to
Component, I expect the cast to be removed
if ((c instanceof JComponent) && (((JComponent)c).isValidateRoot()))
But, when addInvalidComponent() finds no vaidateRoot,
it immediately returns, and this behavior will be affected
I see no strong reasons to make Windows and Applets to be validate
roots, just because it won't give us any benefits and may break the
existing code
Thanks
alexp
For the window method, shouldn't it be marked as final?
And what about the AWT ScrollPane? Shouldn't it return true as well?
Hope this helps,
-Christopher
On Thu, Jul 23, 2009 at 1:57 PM, Anthony Petrov<anthony.pet...@sun.com> wrote:
Hello Swing and AWT teams,
So here's the latest version of the fix:
http://cr.openjdk.java.net/~anthony/7-23-invalidate-6852592.2/
The specification has been modified, some stuff has been moved around.
Currently the spec is being reviewed by the CCC at Sun, and therefore is
kind of frozen. However, if anyone happen to find major problems with the
javadoc, please feel free to speak up.
Suggestions for the code changes are still very welcome. Thank you in
advance!
--
best regards,
Anthony
