Hello Anthony
Hi Alex,
On 7/27/2009 8:41 PM Alexander Potochkin wrote:
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()))
A component cannot be a validate root by logical reasons: it has nothing
to lay out inside itselft, and therefore the state of
validity/invalidity is not relevant to a component. Moreover, a
component does not have children, thus it can't be a 'root' at all.
Therefore I expect the isValidateRoot() method to stay in the Container
class for quite a long time.
It is actually doesn't matter much
Component is the base class for the whole library
and it is ok for it to have some methods
that only make sense it its subclasses
Component.getBaseline() is a good example
It is so inconvenient to type
if ( (c instanceof JComponent) &&
(((JComponent) c).getBaseline()== somethinng))
so AWT team kindly agreed to brought this method up to the Component
even if it makes no sense for AWT components
isValidateRoot() should be checked from different places both on Swing
and AWT sides, so it really make sense to add it to the Component class
Regarding the mentioned condition, it needs to be changed as
s/JComponent/Container/, and so needs to be changed the code around it
to make sure the 'c' is used as a normal AWT container w/o any special
treatment of it as an instance of the JComponent.
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
Besides, please consider a situation when one uses a few Swing
components in an AWT application (which is rare, but not impossible).
While this is not an 'officially supported' kind of mixing, I don't see
reasons why it shouldn't generally work. Now suppose one of the Swing
components is a popup (like a context menu, or a combo box, whatever).
After displaying the popup, the Swing code is expected to call the
revalidate() method which works perfectly in case of a Swing
application. However, since AWT applications normally don't have
validate roots, the addInvalidComponent() will fail to validate the
hierarchy, and we may observe some weird stuff (we do in fact: see the
bug 6862117). That's why I think it is OK to make the Window and the
Applet classes validate roots.
> With the changes to the
> addInvalidComponent() described above, everything should work just
> fine.
Using Swing components in AWT applications is incorrect,
not supported and I doubt it will ever be
Here is the JComponent's javadoc:
* To use a component that inherits from <code>JComponent</code>,
* you must place the component in a containment hierarchy
* whose root is a top-level Swing container.
* Top-level Swing containers --
* such as <code>JFrame</code>, <code>JDialog</code>,
* and <code>JApplet</code> --
So the described scenario is not really relevant
Could you please elaborate on possible situations that could break after
making the Window/Applet the validate root?
Let me describe the "best fix"
1) Bring isValidateRoot() up to the Component class
2) Make it return false
3) Leave all other stuff intact
This proposal is 100% safe and does what we need
Would you agree?
Thanks
alexp
--
best regards,
Anthony
